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:
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:
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:
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:
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.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftct: fix use-after-free in timeout object destroy
nftcttimeoutobjdestroy() frees the timeout object with kfree() immediately after nfctuntimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcudereference() in nfcttimeoutdata().
Add an rcuhead to struct nfcttimeout and use kfreercu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlinkcttimeout.c.
KASAN report: BUG: KASAN: slab-use-after-free in nfconntracktcppacket+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80
Call Trace: nfconntracktcppacket+0x1381/0x29d0 nfconntrackin+0x612/0x8b0 nfhookslow+0x70/0x100 iplocalout+0x1b2/0x210 tcpsendmsglocked+0x722/0x1580 syssendto+0x2d8/0x320
Allocated by task 75: nftcttimeoutobjinit+0xf6/0x290 nftobjinit+0x107/0x1b0 nftablesnewobj+0x680/0x9c0 nfnetlinkrcvbatch+0xc29/0xe00
Freed by task 26: nftobjdestroy+0x3f/0xa0 nftablestransdestroywork+0x51c/0x5c0 processonework+0x2c4/0x5a0
In the Linux kernel, the following vulnerability has been resolved:
net: altera-tse: fix skb leak on DMA mapping error in tsestartxmit()
When dmamapsingle() fails in tsestartxmit(), the function returns NETDEVTXOK without freeing the skb. Since NETDEVTXOK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure.
Add devkfreeskbany() before returning to properly free the skb.
In the Linux kernel, the following vulnerability has been resolved:
net: macb: Use devconsumeskbany() to free TX SKBs
The napiconsumeskb() function is not intended to be called in an IRQ disabled context. However, after commit 6bc8a5098bf4 ("net: macb: Fix txptrlock locking"), the freeing of TX SKBs is performed with IRQs disabled. To resolve the following call trace, use devconsumeskbany() for freeing TX SKBs: WARNING: kernel/softirq.c:430 at localbhenableip+0x174/0x188, CPU#0: ksoftirqd/0/15 Modules linked in: CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.0-rc4-next-20260319-yocto-standard-dirty #37 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : localbhenableip+0x174/0x188 lr : localbhenable+0x24/0x38 sp : ffff800082b3bb10 x29: ffff800082b3bb10 x28: ffff0008031f3c00 x27: 000000000011ede0 x26: ffff000800a7ff00 x25: ffff800083937ce8 x24: 0000000000017a80 x23: ffff000803243a78 x22: 0000000000000040 x21: 0000000000000000 x20: ffff000800394c80 x19: 0000000000000200 x18: 0000000000000001 x17: 0000000000000001 x16: ffff000803240000 x15: 0000000000000000 x14: ffffffffffffffff x13: 0000000000000028 x12: ffff000800395650 x11: ffff8000821d1528 x10: ffff800081c2bc08 x9 : ffff800081c1e258 x8 : 0000000100000301 x7 : ffff8000810426ec x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000008 x1 : 0000000000000200 x0 : ffff8000810428dc Call trace: localbhenableip+0x174/0x188 (P) localbhenable+0x24/0x38 skbattemptdeferfree+0x190/0x1d8 napiconsumeskb+0x58/0x108 macbtxpoll+0x1a4/0x558 napipoll+0x50/0x198 netrxaction+0x1f4/0x3d8 handlesoftirqs+0x16c/0x560 runksoftirqd+0x44/0x80 smpbootthreadfn+0x1d8/0x338 kthread+0x120/0x150 retfromfork+0x10/0x20 irq event stamp: 29751 hardirqs last enabled at (29750): [<ffff8000813be184>] rawspinunlockirqrestore+0x44/0x88 hardirqs last disabled at (29751): [<ffff8000813bdf60>] rawspinlockirqsave+0x38/0x98 softirqs last enabled at (29150): [<ffff8000800f1aec>] handlesoftirqs+0x504/0x560 softirqs last disabled at (29153): [<ffff8000800f2fec>] runksoftirqd+0x44/0x80
futex: Clear stale exiting pointer in futexlockpi() retry path
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix double-free of smcspdpriv when tee() duplicates splice pipe buffer
smcrxsplice() allocates one smcspdpriv per pipebuffer and stores the pointer in pipebuffer.private. The pipebufoperations for these buffers used .get = genericpipebufget, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smcspdpriv pointer itself was not handled, so after tee() both the original and the cloned pipebuffer share the same smcspdpriv .
When both pipes are subsequently released, smcrxpipebufrelease() is called twice against the same object:
1st call: kfree(priv) sockput(sk) smcrxupdatecons() [correct] 2nd call: kfree(priv) sockput(sk) smcrxupdatecons() [UAF]
KASAN reports a slab-use-after-free in smcrxpipebufrelease(), which then escalates to a NULL-pointer dereference and kernel panic via smcrxupdateconsumer() when it chases the freed priv->smc pointer:
BUG: KASAN: slab-use-after-free in smcrxpipebufrelease+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smcsplicetee/74 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xce/0x650 kasanreport+0xc6/0x100 smcrxpipebufrelease+0x78/0x2a0 freepipeinfo+0xd4/0x130 piperelease+0x142/0x160 fput+0x1c6/0x490 x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smcrxupdateconsumer+0x8d/0x350 Call Trace: <TASK> smcrxpipebufrelease+0x121/0x2a0 freepipeinfo+0xd4/0x130 piperelease+0x142/0x160 fput+0x1c6/0x490 x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> Kernel panic - not syncing: Fatal exception
Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smcrxupdatecons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smcspdpriv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately.
The .get callback is invoked by both tee(2) and splicepipetopipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.
In the Linux kernel, the following vulnerability has been resolved:
net: fix fanout UAF in packetrelease() via NETDEVUP race
packetrelease() has a race window where NETDEVUP can re-register a socket into a fanout group's arr[] array. The re-registration is not cleaned up by fanoutrelease(), leaving a dangling pointer in the fanout array. packetrelease() does NOT zero po->num in its bindlock section. After releasing bindlock, po->num is still non-zero and po->ifindex still matches the bound device. A concurrent packetnotifier(NETDEVUP) that already found the socket in sklist can re-register the hook. For fanout sockets, this re-registration calls fanoutlink(sk, po) which adds the socket back into f->arr[] and increments f->nummembers, but does NOT increment f->skref.
The fix sets po->num to zero in packetrelease while bindlock is held to prevent NETDEVUP from linking, preventing the race window.
This bug was found following an additional audit with Claude Code based on CVE-2025-38617.
In the Linux kernel, the following vulnerability has been resolved:
net: macb: use the current queue number for stats
There's a potential mismatch between the memory reserved for statistics and the amount of memory written.
gemgetssetcount() correctly computes the number of stats based on the active queues, whereas gemgetethtoolstats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACBMAXQUEUES, this results in a OOB write as observed in the KASAN splat.
================================================================== BUG: KASAN: vmalloc-out-of-bounds in gemgetethtoolstats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027
CPU: [...] Tainted: [E]=UNSIGNEDMODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: showstack+0x20/0x38 (C) dumpstacklvl+0x80/0xf8 printreport+0x384/0x5e0 kasanreport+0xa0/0xf0 kasancheckrange+0xe8/0x190 asanmemcpy+0x54/0x98 gemgetethtoolstats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] devethtool+0x1220/0x38c0 devioctl+0x4ac/0xca8 sockdoioctl+0x170/0x1d8 sockioctl+0x484/0x5d8 arm64sysioctl+0x12c/0x1b8 invokesyscall+0xd4/0x258 el0svccommon.constprop.0+0xb4/0x240 doel0svc+0x48/0x68 el0svc+0x40/0xf8 el0t64synchandler+0xa0/0xe8 el0t64sync+0x1b0/0x1b8
The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at devethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================
Fix it by making sure the copied size only considers the active number of queues.
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-fsl-lpspi: fix teardown order issue (UAF)
There is a teardown order issue in the driver. The SPI controller is registered using devmspiregistercontroller(), which delays unregistration of the SPI controller until after the fsllpspiremove() function returns.
As the fsllpspiremove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free:
| fsllpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsllpspidmatransfer+0x260/0x340 [spifsllpspi] | fsllpspitransferone+0x198/0x448 [spifsllpspi] | spitransferonemessage+0x49c/0x7c8 | spipumptransfermessage+0x120/0x420 | spisync+0x2c4/0x520 | spisync+0x34/0x60 | spidevmessage+0x20c/0x378 [spidev] | spidevioctl+0x398/0x750 [spidev] [...]
Switch from devmspiregistercontroller() to spiregistercontroller() in fsllpspiprobe() and add the corresponding spiunregistercontroller() in fsllpspiremove().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlinklog: account for netlink header size
This is a followup to an old bug fix: NLMSGDONE needs to account for the netlink header size, not just the attribute size.
This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: serialize lock/unlock against other NAND operations
nandlock() and nandunlock() call into chip->ops.lockarea/unlockarea without holding the NAND device lock. On controllers that implement SETFEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmdpending conflicts on the NAND controller.
Add nandgetdevice()/nandreleasedevice() around the lock/unlock operations to serialize them against all other NAND controller access.
In the Linux kernel, the following vulnerability has been resolved:
dpaa2-switch: Fix interrupt storm after receiving bad ifid in IRQ handler
Commit 31a7a0bbeb00 ("dpaa2-switch: add bounds check for ifid in IRQ handler") introduces a range check for ifid to avoid an out-of-bounds access. If an out-of-bounds ifid is detected, the interrupt status is not cleared. This may result in an interrupt storm.
Clear the interrupt status after detecting an out-of-bounds ifid to avoid the problem.
Found by an experimental AI code review agent at Google.
In the Linux kernel, the following vulnerability has been resolved:
tls: Purge asynchold in tlsdecryptasyncwait()
The asynchold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tlsdecryptasyncwait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally.
A subsequent patch adds batch async decryption to tlsswreadsock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move skbqueuepurge(&ctx->asynchold) into tlsdecryptasyncwait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tlsdodecryption(), and the new readsock batch path -- releases held skbs on synchronization without each site managing the purge independently.
This fixes a leak when tlsstrpmsghold() fails part-way through, after having added some cloned skbs to the asynchold queue. tlsdecryptsg() will then call tlsdecryptasyncwait() to process all pending decrypts, and drop back to synchronous mode, but tlsswrecvmsg() only flushes the asynchold queue when one record has been processed in "fully-async" mode, which may not be the case here.
[pabeni@redhat.com: added leak comment]
In the Linux kernel, the following vulnerability has been resolved:
nfnetlinkosf: validate individual option lengths in fingerprints
nfnlosfaddcallback() validates optnum bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nfosfmatchone() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL:
Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nfosfmatchone (net/netfilter/nfnetlinkosf.c:98) Call Trace: nfosfmatch (net/netfilter/nfnetlinkosf.c:227) xtosfmatchpacket (net/netfilter/xtosf.c:32) iptdotable (net/ipv4/netfilter/iptables.c:293) nfhookslow (net/netfilter/core.c:623) iplocaldeliver (net/ipv4/ipinput.c:262) iprcv (net/ipv4/ipinput.c:573)
Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nfosfmatchone() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses "< 4" rather than "!= 4" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check.
Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: release flowtable after rcu grace period on error
Call synchronizercu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlinkhook control plane.
This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronizercu().
There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised.
Uncovered by KASAN reported as use-after-free from nfnetlinkhook path when dumping hooks.