[26.04_linux-nvidia-bos] CVE may/26.04 linux nvidia bos#434
Conversation
Boro reviewLatest watcher review: open review Head: This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review. |
PR Validation ReportPatchscan
|
ltrager
changed the title
@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? |
|
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. |
@nvmochs oh, that's new. The current scanner won't parse a repo/branch suffix. Can we add 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 |
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. |
Search by subject sounds like a good backup plan. |
ltrager
force-pushed
the
cve-may/26.04_linux-nvidia-bos
branch
from
b922b55 to
a744893
Compare
Let me think about it on how to do that" that means we need the linux-stable branch. |
|
All commits are now tagged with |
|
all six PR commits match the diff of their referenced cherry-picked commits:
|
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). |
nirmoy
added
help wanted
Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/2153497 Properties: no-test-build Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
…rnel-versions (adhoc/d2026.05.20) BugLink: https://bugs.launchpad.net/bugs/1786013 Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Some options were not ordered as the annotations tool expected them to be. Ignore: yes Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
Signed-off-by: Jacob Martin <jacob.martin@canonical.com>
|
Agree with Matt some are upstreams. |
@ltrager ^^ (not sure if you saw this comment earlier since I forgot to tag you) |
ltrager
force-pushed
the
cve-may/26.04_linux-nvidia-bos
branch
2 times, most recently
from
39cc81e to
b40e5fb
Compare
|
ah thanks for pointing that out. I pulled from stable which branches after those patches were applied. |
|
Thanks Lee...no further comments from me.
|
sforshee
left a comment
sforshee
left a comment
There was a problem hiding this comment.
Looks good.
Acked-by: Seth Forshee <sforshee@nvidia.com>
nvidia-bfigg
force-pushed
the
26.04_linux-nvidia-bos
branch
from
b496691 to
3ab3db0
Compare
|
Hey @ltrager |
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
force-pushed
the
cve-may/26.04_linux-nvidia-bos
branch
from
b40e5fb to
af968a3
Compare
nvidia-bfigg
force-pushed
the
26.04_linux-nvidia-bos
branch
from
3ab3db0 to
704a746
Compare
|
Confirmed, the patches are the same post-rebase. I'll submit this to Brad. |
Closing the loop here: Brad has asked us to hold on this PR as these CVE updates may already be included in the latest -stable update from Canonical to the base Ubuntu kernel. Will confirm once that is available. |
10 participants
Fixes the following CVE with clean cherry picks from 7.0 stable
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