[26.04_linux-nvidia-bos] CVE may/26.04 linux nvidia bos by ltrager · Pull Request #434 · NVIDIA/NV-Kernels

ltrager · 2026-05-20T22:56:42Z

Fixes the following CVE with clean cherry picks from 7.0 stable

CVE-2026-43284 - 52646cbd
CVE-2026-43500 - d45179f8
- Note to cleanly apply CVE fix bug fixes 24481a7f, 55b2984c, and 1f274015 had to be applied
CVE-2026-46333 - 01363cb3

LP: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-bos-7.0/+bug/2153504

Tested by building the nvidia-bos kernel and booting on a GH200

nirmoy · 2026-05-20T23:04:48Z

Boro review

Latest watcher review: open review

Head: b40e5fb9a812

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

github-actions · 2026-05-20T23:05:37Z

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ❌ Errors found

Details

Checking 6 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b40e5fb9a812 │ [SAUCE] ptrace: slightly saner 'get_dumpable()' logic            │ N/A        │ N/A     │ torvalds, gregkh, ltrager │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 908e2c557b1f │ [SAUCE] rxrpc: also unshare data/response packets when paged fra │ N/A        │ N/A     │ imv4bel, torvalds, gregkh │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 08097a3eee9d │ 24481a7f5733 rxrpc: Fix conn-level packet handling to unshare RE │ match      │ match   │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 20595b2621f8 │ 55b2984c96c3 rxrpc: Fix rxrpc_input_call_event() to only unshare │ match      │ match   │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 24aa14fe8343 │ 1f2740150f90 rxrpc: Fix potential UAF after skb_unshare() failur │ match      │ match   │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 5e00e0991915 │ [SAUCE] xfrm: esp: avoid in-place decrypt on shared skb frags    │ N/A        │ N/A     │ h3xrabbi, klassert, gregk │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint results:
E: b40e5fb9a812 ("ptrace: slightly saner 'get_dumpable()' logic"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
E: 908e2c557b1f ("rxrpc: Also unshare DATA/RESPONSE packets when pag"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
E: 5e00e0991915 ("xfrm: esp: avoid in-place decrypt on shared skb fr"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)

nvmochs · 2026-05-21T03:21:14Z

PR Validation Report

PR Lint ❌ Errors found

Details
Checking 6 commits...

Cherry-pick digest:
E: b922b55 ("ptrace: slightly saner 'get_dumpable()' "): cannot resolve upstream SHA 01363cb3fbd0
E: a2e4efa ("rxrpc: Also unshare DATA/RESPONSE packet"): cannot resolve upstream SHA d45179f87952
E: b8f73e7 ("xfrm: esp: avoid in-place decrypt on sha"): cannot resolve upstream SHA 52646cbd00e7
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local │ Referenced upstream / Patch subject │ Patch-ID │ Subject │ SoB chain │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b922b55 │ 01363cb3fbd0 │ ERROR │ ERROR │ ERROR │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ a2e4efa │ d45179f87952 │ ERROR │ ERROR │ ERROR │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ f0008f0 │ 24481a7 rxrpc: Fix conn-level packet handling to unshare RE │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 14d9c94 │ 55b2984 rxrpc: Fix rxrpc_input_call_event() to only unshare │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 4f9ffa7 │ 1f27401 rxrpc: Fix potential UAF after skb_unshare() failur │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b8f73e7 │ 52646cbd00e7 │ ERROR │ ERROR │ ERROR │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

@nirmoy I think some of these encountered "errors" because the SHAs were from stable as opposed to Linus' repo. Any thoughts on how we can improve this? If we add a trailing repo/branch after the SHA in the pick tag will the scanner recognize that?

ltrager · 2026-05-21T04:06:26Z

I used stable since upstream handles any merge conflicts allowing us to have clean cherry picks. I can use Linus's tree if that is what is expected.

One thought, can the scanner add a second git remote containing the stable tree? That would allow it to verify the SHAs in the repo without much extra work.

nirmoy · 2026-05-21T12:45:42Z

PR Validation Report

PR Lint ❌ Errors found

Details
Checking 6 commits...
Cherry-pick digest:
E: b922b55 ("ptrace: slightly saner 'get_dumpable()' "): cannot resolve upstream SHA 01363cb3fbd0
E: a2e4efa ("rxrpc: Also unshare DATA/RESPONSE packet"): cannot resolve upstream SHA d45179f87952
E: b8f73e7 ("xfrm: esp: avoid in-place decrypt on sha"): cannot resolve upstream SHA 52646cbd00e7
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local │ Referenced upstream / Patch subject │ Patch-ID │ Subject │ SoB chain │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b922b55 │ 01363cb3fbd0 │ ERROR │ ERROR │ ERROR │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ a2e4efa │ d45179f87952 │ ERROR │ ERROR │ ERROR │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ f0008f0 │ 24481a7 rxrpc: Fix conn-level packet handling to unshare RE │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 14d9c94 │ 55b2984 rxrpc: Fix rxrpc_input_call_event() to only unshare │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 4f9ffa7 │ 1f27401 rxrpc: Fix potential UAF after skb_unshare() failur │ match │ match │ preserved + ltrager added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b8f73e7 │ 52646cbd00e7 │ ERROR │ ERROR │ ERROR │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘
Lint: all checks passed.

@nirmoy I think some of these encountered "errors" because the SHAs were from stable as opposed to Linus' repo. Any thoughts on how we can improve this? If we add a trailing repo/branch after the SHA in the pick tag will the scanner recognize that?

@nvmochs oh, that's new. The current scanner won't parse a repo/branch suffix. Can we add linux-stable as a known remote instead? A generic repo/branch trailer could work too, but then we'd have to fetch that repo/branch every run.

Update: The commit is there in linux repo with different hash. I think I can add a search by subject if hash find fails.

for a2e4efa

nirmoyd@82875d6-lcedt:~/devel/NV-Kernels$ git log --oneline  aa54b1d27fe0c -1
aa54b1d27fe0c rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present

nvmochs · 2026-05-21T13:17:27Z

I used stable since upstream handles any merge conflicts allowing us to have clean cherry picks. I can use Linus's tree if that is what is expected.

One thought, can the scanner add a second git remote containing the stable tree? That would allow it to verify the SHAs in the repo without much extra work.

Picking from linux-stable is fine, but for any patches that are not picked from upstream, please add an identifier after the SHA on the pick line. For the ones in this PR that were picked from -stable, I recommend using "linux-stable".

e.g.

(cherry picked from commit 52646cbd00e765a6db9c3afe9535f26218276034 linux-stable)

nvmochs · 2026-05-21T13:19:09Z

@nirmoy I think some of these encountered "errors" because the SHAs were from stable as opposed to Linus' repo. Any thoughts on how we can improve this? If we add a trailing repo/branch after the SHA in the pick tag will the scanner recognize that?

@nvmochs oh, that's new. The current scanner won't parse a repo/branch suffix. Can we add linux-stable as a known remote instead? A generic repo/branch trailer could work too, but then we'd have to fetch that repo/branch every run.

Update: The commit is there in linux repo with different hash. I think I can add a search by subject if hash find fails.

for a2e4efa
nirmoyd@82875d6-lcedt:~/devel/NV-Kernels$ git log --oneline  aa54b1d27fe0c -1
aa54b1d27fe0c rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present

Search by subject sounds like a good backup plan.

nirmoy · 2026-05-21T16:29:32Z

I used stable since upstream handles any merge conflicts allowing us to have clean cherry picks. I can use Linus's tree if that is what is expected.
One thought, can the scanner add a second git remote containing the stable tree? That would allow it to verify the SHAs in the repo without much extra work.

Picking from linux-stable is fine, but for any patches that are not picked from upstream, please add an identifier after the SHA on the pick line. For the ones in this PR that were picked from -stable, I recommend using "linux-stable".

Let me think about it on how to do that"

if the commit exist in linux-stable
then check if the trailer has linux-stable

that means we need the linux-stable branch.

ltrager · 2026-05-21T16:38:41Z

All commits are now tagged with (Cherry picked from commit <SHA> linux-stable)

nirmoy · 2026-05-21T17:01:30Z

all six PR commits match the diff of their referenced cherry-picked commits:

Acked-by: Nirmoy Das <nirmoyd@nvidia.com>

nvmochs · 2026-05-21T17:38:30Z

All commits are now tagged with (Cherry picked from commit <SHA> linux-stable)

But not all of these were picked from linux-stable.

It looks like these three were picked from upstream, so they do not require an identifier after the SHA (or if you prefer to include an identifier, it should be linux).

bcf262e8b603 rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
0cfed1dea3a0 rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets
6e3e535fa7cf rxrpc: Fix potential UAF after skb_unshare() failure

clsotog · 2026-05-21T21:36:19Z

Agree with Matt some are upstreams.

nvmochs · 2026-05-21T23:17:10Z

All commits are now tagged with (Cherry picked from commit <SHA> linux-stable)

But not all of these were picked from linux-stable.

It looks like these three were picked from upstream, so they do not require an identifier after the SHA (or if you prefer to include an identifier, it should be linux).
bcf262e8b603 rxrpc: Fix conn-level packet handling to unshare RESPONSE packets
0cfed1dea3a0 rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets
6e3e535fa7cf rxrpc: Fix potential UAF after skb_unshare() failure

@ltrager ^^ (not sure if you saw this comment earlier since I forgot to tag you)

commit f4c50a4 upstream. MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(), so later paths that may modify packet data can first make a private copy. The IPv4/IPv6 datagram append paths did not set this flag when splicing pages into UDP skbs. That leaves an ESP-in-UDP packet made from shared pipe pages looking like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW fast path for uncloned skbs without a frag_list and decrypts in place over data that is not owned privately by the skb. Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching TCP. Also make ESP input fall back to skb_cow_data() when the flag is present, so ESP does not decrypt externally backed frags in place. Private nonlinear skb frags still use the existing fast path. This intentionally does not change ESP output. In esp_output_head(), the path that appends the ESP trailer to existing skb tailroom without calling skb_cow_data() is not reachable for nonlinear skbs: skb_tailroom() returns zero when skb->data_len is nonzero, while ESP tailen is positive. Thus ESP output will either use the separate destination-frag path or fall back to skb_cow_data(). Fixes: cac2661 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30 ("esp6: Avoid skb_cow_data whenever possible") Fixes: 7da0dde ("ip, udp: Support MSG_SPLICE_PAGES") Fixes: 6d8192b ("ip6, udp6: Support MSG_SPLICE_PAGES") Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Reported-by: Kuan-Ting Chen <h3xrabbit@gmail.com> Tested-by: Hyunwoo Kim <imv4bel@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Kuan-Ting Chen <h3xrabbit@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 52646cbd00e765a6db9c3afe9535f26218276034 linux-stable) Signed-off-by: Lee Trager <ltrager@nvidia.com>

If skb_unshare() fails to unshare a packet due to allocation failure in rxrpc_input_packet(), the skb pointer in the parent (rxrpc_io_thread()) will be NULL'd out. This will likely cause the call to trace_rxrpc_rx_done() to oops. Fix this by moving the unsharing down to where rxrpc_input_call_event() calls rxrpc_input_call_packet(). There are a number of places prior to that where we ignore DATA packets for a variety of reasons (such as the call already being complete) for which an unshare is then avoided. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 2d1faf7 ("rxrpc: Simplify skbuff accounting in receive path") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-4-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 1f27401) Signed-off-by: Lee Trager <ltrager@nvidia.com>

Fix rxrpc_input_call_event() to only unshare DATA packets and not ACK, ABORT, etc.. And with that, rxrpc_input_packet() doesn't need to take a pointer to the pointer to the packet, so change that to just a pointer. Fixes: 1f27401 ("rxrpc: Fix potential UAF after skb_unshare() failure") Closes: https://sashiko.dev/#/patchset/20260422161438.2593376-4-dhowells@redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260423200909.3049438-2-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 55b2984) Signed-off-by: Lee Trager <ltrager@nvidia.com>

The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted). Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned. Fixes: 17926a7 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Closes: https://sashiko.dev/#/patchset/20260408121252.2249051-1-dhowells%40redhat.com Signed-off-by: David Howells <dhowells@redhat.com> cc: Marc Dionne <marc.dionne@auristor.com> cc: Jeffrey Altman <jaltman@auristor.com> cc: Simon Horman <horms@kernel.org> cc: linux-afs@lists.infradead.org cc: stable@kernel.org Link: https://patch.msgid.link/20260422161438.2593376-5-dhowells@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 24481a7) Signed-off-by: Lee Trager <ltrager@nvidia.com>

commit aa54b1d upstream. The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused. Fixes: d0d5c0c ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d45179f8795222ce858770dc619abe51f9d24411 linux-stable) Signed-off-by: Lee Trager <ltrager@nvidia.com>

commit 31e62c2 upstream. The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACE_MODE_READ_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads). It's not what this flag was designed for, but it is what it is. The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all. Make it all make a *bit* more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAP_SYS_PTRACE capability to override. Reported-by: Qualys Security Advisory <qsa@qualys.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 01363cb3fbd0238ffdeb09f53e9039c9edf8a730 linux-stable) Signed-off-by: Lee Trager <ltrager@nvidia.com>

ltrager · 2026-05-21T23:58:10Z

ah thanks for pointing that out. I pulled from stable which branches after those patches were applied.

nvmochs · 2026-05-22T01:10:42Z

Thanks Lee...no further comments from me.

Acked-by: Matthew R. Ochs <mochs@nvidia.com>

sforshee

Looks good.

Acked-by: Seth Forshee <sforshee@nvidia.com>

ltrager changed the title ~~CVE may/26.04 linux nvidia bos~~ [26.04_linux-nvidia-bos] CVE may/26.04 linux nvidia bos May 20, 2026

ltrager force-pushed the cve-may/26.04_linux-nvidia-bos branch from b922b55 to a744893 Compare May 21, 2026 16:21

nirmoy added help wanted Extra attention is needed question Further information is requested labels May 21, 2026

ltrager force-pushed the cve-may/26.04_linux-nvidia-bos branch from a744893 to 39cc81e Compare May 21, 2026 23:48

HexRabbit and others added 6 commits May 21, 2026 23:52

ltrager force-pushed the cve-may/26.04_linux-nvidia-bos branch from 39cc81e to b40e5fb Compare May 21, 2026 23:54

sforshee reviewed May 22, 2026

View reviewed changes

Conversation

ltrager commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nirmoy commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Boro review

Uh oh!

github-actions Bot commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Validation Report

Patchscan ✅ No Missing Fixes

PR Lint ❌ Errors found

Uh oh!

nvmochs commented May 21, 2026

PR Validation Report

PR Lint ❌ Errors found

Uh oh!

ltrager commented May 21, 2026

Uh oh!

nirmoy commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Validation Report

PR Lint ❌ Errors found

Uh oh!

nvmochs commented May 21, 2026

Uh oh!

nvmochs commented May 21, 2026

Uh oh!

nirmoy commented May 21, 2026

Uh oh!

ltrager commented May 21, 2026

Uh oh!

nirmoy commented May 21, 2026

Uh oh!

nvmochs commented May 21, 2026

Uh oh!

clsotog commented May 21, 2026

Uh oh!

nvmochs commented May 21, 2026

Uh oh!

ltrager commented May 21, 2026

Uh oh!

nvmochs commented May 22, 2026

Uh oh!

sforshee left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

ltrager commented May 20, 2026 •

edited

Loading

nirmoy commented May 20, 2026 •

edited

Loading

github-actions Bot commented May 20, 2026 •

edited

Loading

nirmoy commented May 21, 2026 •

edited

Loading