In the Linux kernel, the following vulnerability has been resolved:

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NFHOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NFSTOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

In the Linux kernel, the following vulnerability has been resolved:

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

crypto: algifaead - Revert to operating out-of-place

In the Linux kernel, the following vulnerability has been resolved:

RDMA/efa: Fix use of completion ctx after free

On admin queue completion handling, if the admin command completed with error we print data from the completion context. The issue is that we already freed the completion context in polling/interrupts handler which means we print data from context in an unknown state (it might be already used again). Change the admin submission flow so alloc/dealloc of the context will be symmetric and dealloc will be called after any potential use of the context.

In the Linux kernel, the following vulnerability has been resolved:

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.

In the Linux kernel, the following vulnerability has been resolved:

module: Fix kernel panic when a symbol stshndx is out of bounds

The module loader doesn't check for bounds of the ELF section index in simplifysymbols():

for (i = 1; i < symsec->shsize / sizeof(ElfSym); i++) { const char name = info->strtab + sym[i].stname;

switch (sym[i].stshndx) { case SHNCOMMON:

[...]

default: / Divert to percpu allocation if a percpu var. / if (sym[i].stshndx == info->index.pcpu) secbase = (unsigned long)modpercpu(mod); else / HERE --> / secbase = info->sechdrs[sym[i].stshndx].shaddr; sym[i].stvalue += secbase; break; } }

A symbol with an out-of-bounds stshndx value, for example 0xffff (known as SHNXINDEX or SHNHIRESERVE), may cause a kernel panic:

BUG: unable to handle page fault for address: ... RIP: 0010:simplifysymbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception

This can happen when module ELF is legitimately using SHNXINDEX or when it is corrupted.

Add a bounds check in simplifysymbols() to validate that stshndx is within the valid range before using it.

This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1].

[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/

btrfs: set BTRFSROOTORPHANCLEANUP during subvol create

In the Linux kernel, the following vulnerability has been resolved:

xfrm: prevent policyhthresh.work from racing with netns teardown

A XFRMMSGNEWSPDINFO request can queue the per-net work item policyhthresh.work onto the system workqueue.

The queued callback, xfrmhashrebuild(), retrieves the enclosing struct net via containerof(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrmhashrebuild() may then dereference stale memory.

xfrmpolicyfini() already flushes policyhashwork during teardown, but it does not synchronize policyhthresh.work.

Synchronize policyhthresh.work in xfrmpolicyfini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.

esp: fix skb leak with espintcp and async crypto

afkey: validate families in pfkeysendmigrate()

In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: Avoid releasing netdev before teardown completes

The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdevdestroy() callback can proceed immediately to the callrcu() invocation if the IFFOVSDATAPATH flag is already cleared on the netdev.

The ovsnetdevdetachdev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdevdestroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like:

[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el102.x8664+rt #1 PREEMPTRT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:devsetpromiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] <TASK> [ 998.393952] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393961] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393975] ? dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394009] ? diebody.cold+0x8/0x12 [ 998.394016] ? dieaddr+0x3c/0x60 [ 998.394027] ? excgeneralprotection+0x16d/0x390 [ 998.394042] ? asmexcgeneralprotection+0x26/0x30 [ 998.394058] ? devsetpromiscuity+0x8d/0xa0 [ 998.394066] ? ovsnetdevdetachdev+0x3a/0x80 [openvswitch] [ 998.394092] dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394102] notifiercallchain+0x5a/0xd0 [ 998.394106] unregisternetdevicemanynotify+0x51b/0xa60 [ 998.394110] rtnldellink+0x169/0x3e0 [ 998.394121] ? rtmutexslowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlinkrcvmsg+0x142/0x3f0 [ 998.394128] ? avchaspermnoaudit+0x69/0xf0 [ 998.394130] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 998.394132] netlinkrcvskb+0x50/0x100 [ 998.394138] netlinkunicast+0x292/0x3f0 [ 998.394141] netlinksendmsg+0x21b/0x470 [ 998.394145] syssendmsg+0x39d/0x3d0 [ 998.394149] syssendmsg+0x9a/0xe0 [ 998.394156] syssendmsg+0x7a/0xd0 [ 998.394160] dosyscall64+0x7f/0x170 [ 998.394162] entrySYSCALL64afterhwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

spi: meson-spicc: Fix double-put in remove path

mesonspiccprobe() registers the controller with devmspiregistercontroller(), so teardown already drops the controller reference via devm cleanup.

Calling spicontrollerput() again in mesonspiccremove() causes a double-put.

hwmon: (pmbus/core) Protect regulator operations with mutex

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix "scheduling while atomic" in IPsec MAC address query

Fix a "scheduling while atomic" bug in mlx5eipsecinitmacs() by replacing mlx5querymacaddress() with etheraddrcopy() to get the local MAC address directly from netdev->devaddr.

The issue occurs because mlx5querymacaddress() queries the hardware which involves mlx5cmdexec() that can sleep, but it is called from the mlx5eipsechandleevent workqueue which runs in atomic context.

The MAC address is already available in netdev->devaddr, so no need to query hardware. This avoids the sleeping call and resolves the bug.

Call trace: BUG: scheduling while atomic: kworker/u112:2/69344/0x00000200 schedule+0x7ab/0xa20 schedule+0x1c/0xb0 scheduletimeout+0x6e/0xf0 waitforcommon+0x91/0x1b0 cmdexec+0xa85/0xff0 [mlx5core] mlx5cmdexec+0x1f/0x50 [mlx5core] mlx5querynicvportmacaddress+0x7b/0xd0 [mlx5core] mlx5querymacaddress+0x19/0x30 [mlx5core] mlx5eipsecinitmacs+0xc1/0x720 [mlx5core] mlx5eipsecbuildaccelxfrmattrs+0x422/0x670 [mlx5core] mlx5eipsechandleevent+0x2b9/0x460 [mlx5core] processonework+0x178/0x2e0 workerthread+0x2ea/0x430

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: proc: size address buffers for %pISpc output

The AFRXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc".

That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6addrisisatap().

As a result, a case such as

[ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535

is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c.

Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf().

Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example

In the Linux kernel, the following vulnerability has been resolved:

s390/mm: Add missing secure storage access fixups for donated memory

There are special cases where secure storage access exceptions happen in a kernel context for pages that don't have the PGarch1 bit set. That bit is set for non-exported guest secure storage (memory) but is absent on storage donated to the Ultravisor since the kernel isn't allowed to export donated pages.

Prior to this patch we would try to export the page by calling archmakefolioaccessible() which would instantly return since the arch bit is absent signifying that the page was already exported and no further action is necessary. This leads to secure storage access exception loops which can never be resolved.

With this patch we unconditionally try to export and if that fails we fixup.

In the Linux kernel, the following vulnerability has been resolved:

nvmet: move async event work off nvmet-wq

For target nvmetctrlfree() flushes ctrl->asynceventwork. If nvmetctrlfree() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-

A. Async event work queued on nvmet-wq (prior to disconnect): nvmetexecuteasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

nvmetaddasyncevent() queuework(nvmetwq, &ctrl->asynceventwork)

B. Full pre-work chain (RDMA CM path): nvmetrdmacmhandler() nvmetrdmaqueuedisconnect() nvmetrdmaqueuedisconnect() queuework(nvmetwq, &queue->releasework) processonework() lock((wqcompletion)nvmet-wq) <--------- 1st nvmetrdmareleasequeuework()

C. Recursive path (same worker): nvmetrdmareleasequeuework() nvmetrdmafreequeue() nvmetsqdestroy() nvmetctrlput() nvmetctrlfree() flushwork(&ctrl->asynceventwork) flushwork() touchwqlockdepmap() lock((wqcompletion)nvmet-wq) <--------- 2nd

Lockdep splat:

============================================ WARNING: possible recursive locking detected 6.19.0-rc3nvme+ #14 Tainted: G N -------------------------------------------- kworker/u192:42/44933 is trying to acquire lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: touchwqlockdepmap+0x26/0x90

but task is already holding lock: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660

3 locks held by kworker/u192:42/44933: #0: ffff888118a00948 ((wqcompletion)nvmet-wq){+.+.}-{0:0}, at: processonework+0x53e/0x660 #1: ffffc9000e6cbe28 ((workcompletion)(&queue->releasework)){+.+.}-{0:0}, at: processonework+0x1c5/0x660 #2: ffffffff82d4db60 (rcureadlock){....}-{1:3}, at: flushwork+0x62/0x530

Workqueue: nvmet-wq nvmetrdmareleasequeuework [nvmetrdma] Call Trace: flushwork+0x268/0x530 nvmetctrlfree+0x140/0x310 [nvmet] nvmetcqput+0x74/0x90 [nvmet] nvmetrdmafreequeue+0x23/0xe0 [nvmetrdma] nvmetrdmareleasequeuework+0x19/0x50 [nvmetrdma] processonework+0x206/0x660 workerthread+0x184/0x320 kthread+0x10c/0x240 retfromfork+0x319/0x390

Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.

iavf: fix out-of-bounds writes in iavfgetethtoolstats()

In the Linux kernel, the following vulnerability has been resolved:

net: bcmasp: fix double free of WoL irq

We do not need to free wolirq since it was instantiated with devmrequestirq(). So devres will free for us.

bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing

In the Linux kernel, the following vulnerability has been resolved:

PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry

Endpoint drivers use dwpcieepraisemsixirq() to raise an MSI-X interrupt to the host using a writel(), which generates a PCI posted write transaction. There's no completion for posted writes, so the writel() may return before the PCI write completes. dwpcieepraisemsixirq() also unmaps the outbound ATU entry used for the PCI write, so the write races with the unmap.

If the PCI write loses the race with the ATU unmap, the write may corrupt host memory or cause IOMMU errors, e.g., these when running fio with a larger queue depth against nvmet-pci-epf:

arm-smmu-v3 fc900000.iommu: 0x0000010000000010 arm-smmu-v3 fc900000.iommu: 0x0000020000000000 arm-smmu-v3 fc900000.iommu: 0x000000090000f040 arm-smmu-v3 fc900000.iommu: 0x0000000000000000 arm-smmu-v3 fc900000.iommu: event: FTRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0 arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0

Flush the write by performing a readl() of the same address to ensure that the write has reached the destination before the ATU entry is unmapped.

The same problem was solved for dwpcieepraisemsiirq() in commit 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but there it was solved by dedicating an outbound iATU only for MSI. We can't do the same for MSI-X because each vector can have a different msgaddr and the msgaddr may be changed while the vector is masked.

[bhelgaas: commit log]

In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix soft lockup in mptcprecvmsg()

syzbot reported a soft lockup in mptcprecvmsg() [0].

When receiving data with MSGPEEK | MSGWAITALL flags, the skb is not removed from the skreceivequeue. This causes skwaitdata() to always find available data and never perform actual waiting, leading to a soft lockup.

Fix this by adding a 'last' parameter to track the last peeked skb. This allows skwaitdata() to make informed waiting decisions and prevent infinite loops when MSGPEEK is used.

[0]: watchdog: BUG: soft lockup - CPU#2 stuck for 156s! [server:1963] Modules linked in: CPU: 2 UID: 0 PID: 1963 Comm: server Not tainted 6.19.0-rc8 #61 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skwaitdata+0x15/0x190 Code: 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 41 56 41 55 41 54 49 89 f4 55 48 89 d5 53 48 89 fb <48> 83 ec 30 65 48 8b 05 17 a4 6b 01 48 89 44 24 28 31 c0 65 48 8b RSP: 0018:ffffc90000603ca0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888102bf0800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffc90000603d18 RDI: ffff888102bf0800 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000101 R10: 0000000000000000 R11: 0000000000000075 R12: ffffc90000603d18 R13: ffff888102bf0800 R14: ffff888102bf0800 R15: 0000000000000000 FS: 00007f6e38b8c4c0(0000) GS:ffff8881b877e000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055aa7bff1680 CR3: 0000000105cbe000 CR4: 00000000000006f0 Call Trace: <TASK> mptcprecvmsg+0x547/0x8c0 net/mptcp/protocol.c:2329 inetrecvmsg+0x11f/0x130 net/ipv4/afinet.c:891 sockrecvmsg+0x94/0xc0 net/socket.c:1100 sysrecvfrom+0xb2/0x130 net/socket.c:2256 x64sysrecvfrom+0x1f/0x30 net/socket.c:2267 dosyscall64+0x59/0x2d0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e arch/x86/entry/entry64.S:131 RIP: 0033:0x7f6e386a4a1d Code: 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8d 05 f1 de 2c 00 41 89 ca 8b 00 85 c0 75 20 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6b f3 c3 66 0f 1f 84 00 00 00 00 00 41 56 41 RSP: 002b:00007ffc3c4bb078 EFLAGS: 00000246 ORIGRAX: 000000000000002d RAX: ffffffffffffffda RBX: 000000000000861e RCX: 00007f6e386a4a1d RDX: 00000000000003ff RSI: 00007ffc3c4bb150 RDI: 0000000000000004 RBP: 00007ffc3c4bb570 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000103 R11: 0000000000000246 R12: 00005605dbc00be0 R13: 00007ffc3c4bb650 R14: 0000000000000000 R15: 0000000000000000 </TASK>

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: RX, Fix XDP multi-buf frag counting for legacy RQ

XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.

Such issue can be observed with the testxdpnativeadjsttailshrnkdata selftest when using a payload of 3600 and shrinking by 256 bytes (an upcoming selftest patch): the last fragment gets released by the XDP code but doesn't get tracked by the driver. This results in a negative pprefcount during page release and the following splat:

WARNING: include/net/pagepool/helpers.h:297 at mlx5epagereleasefragmented.isra.0+0x4a/0x50 [mlx5core], CPU#12: ip/3137 Modules linked in: [...] CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0x4a/0x50 [mlx5core] [...] Call Trace: <TASK> mlx5edeallocrxwqe+0xcb/0x1a0 [mlx5core] mlx5efreerxdescs+0x7f/0x110 [mlx5core] mlx5ecloserq+0x50/0x60 [mlx5core] mlx5eclosequeues+0x36/0x2c0 [mlx5core] mlx5eclosechannel+0x1c/0x50 [mlx5core] mlx5eclosechannels+0x45/0x80 [mlx5core] mlx5esafeswitchparams+0x1a5/0x230 [mlx5core] mlx5echangemtu+0xf3/0x2f0 [mlx5core] netifsetmtuext+0xf1/0x230 dosetlink.isra.0+0x219/0x1180 rtnlnewlink+0x79f/0xb60 rtnetlinkrcvmsg+0x213/0x3a0 netlinkrcvskb+0x48/0xf0 netlinkunicast+0x24a/0x350 netlinksendmsg+0x1ee/0x410 socksendmsg+0x38/0x60 syssendmsg+0x232/0x280 syssendmsg+0x78/0xb0 syssendmsg+0x5f/0xb0 [...] dosyscall64+0x57/0xc50

This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDPPASS). This is basically reverting to the original counting before the commit in the fixes tag.

As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nrfrags.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: flowtable: strictly check for maximum number of actions

The maximum number of flowtable hardware offload actions in IPv6 is:

ethernet mangling (4 payload actions, 2 for each ethernet address) SNAT (4 payload actions) DNAT (4 payload actions) Double VLAN (4 vlan actions, 2 for popping vlan, and 2 for pushing) for QinQ. Redirect (1 action)

Which makes 17, while the maximum is 16. But actct supports for tunnels actions too. Note that payload action operates at 32-bit word level, so mangling an IPv6 address takes 4 payload actions.

Update flowactionentrynext() calls to check for the maximum number of supported actions.

While at it, rise the maximum number of actions per flow from 16 to 24 so this works fine with IPv6 setups.

In the Linux kernel, the following vulnerability has been resolved:

net: usb: cdcncm: add ndpoffset to NDP16 nframes bounds check

cdcncmrxverifyndp16() validates that the NDP header and its DPE entries fit within the skb. The first check correctly accounts for ndpoffset:

if ((ndpoffset + sizeof(struct usbcdcncmndp16)) > skbin->len)

but the second check omits it:

if ((sizeof(struct usbcdcncmndp16) + ret (sizeof(struct usbcdcncmdpe16))) > skbin->len)

This validates the DPE array size against the total skb length as if the NDP were at offset 0, rather than at ndpoffset. When the NDP is placed near the end of the NTB (large wNdpIndex), the DPE entries can extend past the skb data buffer even though the check passes. cdcncmrxfixup() then reads out-of-bounds memory when iterating the DPE array.

Add ndpoffset to the nframes bounds check and use structsizet() to express the NDP-plus-DPE-array size more clearly.

In the Linux kernel, the following vulnerability has been resolved:

net: usb: cdcncm: add ndpoffset to NDP32 nframes bounds check

The same bounds-check bug fixed for NDP16 in the previous patch also exists in cdcncmrxverifyndp32(). The DPE array size is validated against the total skb length without accounting for ndpoffset, allowing out-of-bounds reads when the NDP32 is placed near the end of the NTB.

Add ndpoffset to the nframes bounds check and use structsizet() to express the NDP-plus-DPE-array size more clearly.

Compile-tested only.

bpf: Fix incorrect pruning due to atomic fetch precision tracking

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: ensure safe access to master conntrack

Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid.

To access exp->master safely:

- Grab the nfconntrackexpectlock, this gets serialized with cleanfromlists() which also holds this lock when the master conntrack goes away.

- Hold reference on master conntrack via nfconntrackfindget(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths.

This patch goes for extending the nfconntrackexpectlock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section.

The add expectation command already holds a reference to the master conntrack from ctnetlinkcreateexpect().

However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nfctexpectiteratenet() calls already grabs the spinlock while iterating over the expectation table, which is correct.

The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFPKERNEL.

For the expectation events, the IPEXPDESTROY event is already delivered under the spinlock, just move the delivery of IPEXPNEW under the spinlock too because the master conntrack event cache is reached through exp->master.

While at it, add lockdep notations to help identify what codepaths need to grab the spinlock.

In the Linux kernel, the following vulnerability has been resolved:

ext4: validate pidx bounds in ext4extcorrectindexes

ext4extcorrectindexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].pidx->eiblock, there is no validation that pidx falls within the valid range of index entries for that level.

If the on-disk extent header contains a corrupted or crafted ehentries value, pidx can point past the end of the allocated buffer, causing a slab-out-of-bounds read.

Fix this by validating path[k].pidx against EXTLASTINDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.

In the Linux kernel, the following vulnerability has been resolved:

net: correctly handle tunneled traffic on IPV6CSUM GSO fallback

NETIFFIPV6CSUM only advertises support for checksum offload of packets without IPv6 extension headers. Packets with extension headers must fall back onto software checksumming. Since TSO depends on checksum offload, those must revert to GSO.

The below commit introduces that fallback. It always checks network header length. For tunneled packets, the inner header length must be checked instead. Extend the check accordingly.

A special case is tunneled packets without inner IP protocol. Such as RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by transport header either, so also must revert to the software GSO path.