APPLIED: [SRU][Q/R][PATCH 0/1] net/rds: reset op_nents when zerocopy page pin fails
Edoardo Canepa
edoardo.canepa at canonical.com
Fri May 22 16:14:34 UTC 2026
Applied to Q/R:linux/master-next. Thanks.
Added missing buglink as per previous comment
On 5/22/26 03:08, Benjamin Wheeler wrote:
> BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2153962
>
> SRU Justification:
>
> [Impact]
>
> When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(),
> the pinned pages are released with put_page(), and
> rm->data.op_mmp_znotifier is cleared. But we fail to properly
> clear rm->data.op_nents.
>
> Later when rds_message_purge() is called from rds_sendmsg() the
> cleanup loop iterates over the incorrectly non zero number of
> op_nents and frees them again.
>
>
> [Fix]
>
> Fix this by properly resetting op_nents when it should be in
> rds_message_zcopy_from_user().
>
> [Test Plan]
>
> Compiled, boot tested, and ran reproducer (found at
> https://github.com/v12-security/pocs/tree/main/pintheft).
>
>
> [Where problems could occur]
>
> The fix is a single line change to the rds_message_zcopy_from_user()
> function, which is only called from rds_sendmsg() when the caller has
> requested zero-copy send. If there are any issues with this patch, they
> would likely be limited to zero-copy send operations in RDS.
>
>
> Allison Henderson (1):
> net/rds: reset op_nents when zerocopy page pin fails
>
> net/rds/message.c | 1 +
> 1 file changed, 1 insertion(+)
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x20F88172E14F6784.asc
Type: application/pgp-keys
Size: 3167 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260522/5f974c1a/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260522/5f974c1a/attachment.sig>
More information about the kernel-team
mailing list