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

Revert "wireguard: device: enable threaded NAPI"

This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream.

We have had three independent production user reports in combination with Cilium utilizing WireGuard as encryption underneath that k8s Pod E/W traffic to certain peer nodes fully stalled. The situation appears as follows:

- Occurs very rarely but at random times under heavy networking load. - Once the issue triggers the decryption side stops working completely for that WireGuard peer, other peers keep working fine. The stall happens also for newly initiated connections towards that particular WireGuard peer. - Only the decryption side is affected, never the encryption side. - Once it triggers, it never recovers and remains in this state, the CPU/mem on that node looks normal, no leak, busy loop or crash. - bpftrace on the affected system shows that wgprevqueueenqueue fails, thus the MAXQUEUEDPACKETS (1024 skbs!) for the peer's rxqueue is reached. - Also, bpftrace shows that wgpacketrxpoll for that peer is never called again after reaching this state for that peer. For other peers wgpacketrxpoll does get called normally. - Commit db9ae3b ("wireguard: device: enable threaded NAPI") switched WireGuard to threaded NAPI by default. The default has not been changed for triggering the issue, neither did CPU hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always return valid online CPU in wgcpumaskchooseonline()")). - The issue has been observed with stable kernels of v5.15 as well as v6.1. It was reported to us that v5.10 stable is working fine, and no report on v6.6 stable either (somewhat related discussion in [0] though). - In the WireGuard driver the only material difference between v5.10 stable and v5.15 stable is the switch to threaded NAPI by default.

[0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/

Breakdown of the problem:

1) skbs arriving for decryption are enqueued to the peer->rxqueue in wgpacketconsumedata via wgqueueenqueueperdeviceandpeer. 2) The latter only moves the skb into the MPSC peer queue if it does not surpass MAXQUEUEDPACKETS (1024) which is kept track in an atomic counter via wgprevqueueenqueue. 3) In case enqueueing was successful, the skb is also queued up in the device queue, round-robin picks a next online CPU, and schedules the decryption worker. 4) The wgpacketdecryptworker, once scheduled, picks these up from the queue, decrypts the packets and once done calls into wgqueueenqueueperpeerrx. 5) The latter updates the state to PACKETSTATECRYPTED on success and calls napischedule on the per peer->napi instance. 6) NAPI then polls via wgpacketrxpoll. wgprevqueuepeek checks on the peer->rxqueue. It will wgprevqueuedequeue if the queue->peeked skb was not cached yet, or just return the latter otherwise. (wgprevqueuedroppeeked later clears the cache.) 7) From an ordering perspective, the peer->rxqueue has skbs in order while the device queue with the per-CPU worker threads from a global ordering PoV can finish the decryption and signal the skb PACKETSTATECRYPTED out of order. 8) A situation can be observed that the first packet coming in will be stuck waiting for the decryption worker to be scheduled for a longer time when the system is under pressure. 9) While this is the case, the other CPUs in the meantime finish decryption and call into napischedule. 10) Now in wgpacketrxpoll it picks up the first in-order skb from the peer->rxqueue and sees that its state is still PACKETSTATEUNCRYPTED. The NAPI poll routine then exits e ---truncated---

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

ppp: require CAPNETADMIN in target netns for unattached ioctls

/dev/ppp open is currently authorized against file->fcred->userns, while unattached administrative ioctls operate on current->nsproxy->netns.

As a result, a local unprivileged user can create a new user namespace with CLONENEWUSER, gain CAPNETADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace.

Require CAPNETADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls.

This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.

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

i3c: master: svc: bound IBI payload to the requested maxpayloadlen

svci3cmasterhandleibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVCI3CFIFOSIZE), not by the slot size.

slot->data points into the IBI pool, which i3cgenericibiallocpool() sizes at maxpayloadlen per slot. svci3cmasterrequestibi() only rejects a maxpayloadlen larger than SVCI3CFIFOSIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool.

Bound the loop by dev->ibi->maxpayloadlen and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer.

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

s390/vfio-ap: Fix missing lock required to access list of apmatrixmdev objects

In order to traverse or add/remove apmatrixmdev objects in the matrixdev->mdevlist, the matrixdev->guestslock mutex must be held. There are two functions that access the list without holding the mutex:

vfioapmdevprobe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfioapmdevprobe function uses the matrixdev->mdevslock mutex to guard the add of a newly created apmatrixmdev object to the matrixdev->mdevlist. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an apmatrixmdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently.

The adding of an apmatrixmdev object to matrixdev->mdevlist is now guarded by the matrixdev->guestslock which is the correct way to protect against concurrent mdevlist access.

Also removed the following two lines of code because the matrixmdev is allocated via vfioallocdevice macro which uses kzalloc, so reqtrigger and cfgchgtrigger are already zero-initialised when the struct is allocated before the call to vfioregisteremulatediommudev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace.

matrixmdev->reqtrigger = NULL; matrixmdev->cfgchgtrigger = NULL;

vfioapmdevforqueue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The statusshow function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfioapmdevforqueue function which iterates the matrixdev->mdevlist to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrixdev->guestslock mutex must be held.

To fix this, the guestslock mutex is taken prior to taking the matrixdev->mdevslock mutex in the statusshow function. It is taken there rather than the vfioapmdevforqueue function - where it is needed - because it must be taken prior to the mdevslock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevslock is needed there to access fields within the matrixmdev object in that function.

See the vfio-ap-locking.rst in the linux kernel tree.

ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF

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

smb: client: validate absolute native symlink targets before NT fixups

With symlinkroot unset, an absolute target is copied without conversion to an NT drive path. Later code still assumes an NT prefix is present when modifying the target and calculating the print name length.

For "/ab", this causes two failures: sym[5] and path[5] are written past their allocations, and plen -= 2 poff subtracts an assumed 8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534. That underflow causes another overflow: memcpy() copies 65534 bytes into a 24-byte buffer. A user with write access to a mounted share can trigger these bugs with default settings.

Validate the NT drive prefix, including an ASCII drive letter, before accessing fixed offsets or subtracting the prefix length.

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

scsi: libiscsi: Validate the ITT reflected in a Reject PDU

A Reject PDU carries a copy of the header it rejects, and iscsihandlereject() takes the ITT out of that copy to find the task to clean up:

memcpy(&rejectedpdu, data, sizeof(struct iscsihdr)); ... task = iscsiitttotask(conn, rejectedpdu.itt);

That value is whatever the target put there. iscsiitttotask() bounds the index against cmdsmax and checks nothing else, so any task in the pool can be named, and iscsinopoutrsp() then completes it.

An index that has never been used gives a NULL task->conn: the pool is zeroed at session setup and conn is assigned only when a task is allocated. If the task was used and returned, iscsicompletetask() hits its WARNONONCE(task->state == ISCSITASKFREE) and the refcount underflows. An in-flight SCSI command is completed as successful - a 1 MiB read returned 1048576 with none of its buffer written and no warning.

Validate the reflected ITT the way iscsiitttoctask() validates a command ITT, and require the task to be in flight and not a SCSI command.

[ 6.248477] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.249357] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.249951] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.250718] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.251616] RIP: 0010:iscsinopoutrsp.constprop.0+0x46/0x160 [ 6.252043] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.252813] RSP: 0018:ffff88806c907b80 EFLAGS: 00010206 [ 6.253042] RAX: dffffc0000000000 RBX: ffff88800607e000 RCX: ffffffff8d571a25 [ 6.253345] RDX: 000000000000000c RSI: ffff88806c907c38 RDI: 0000000000000060 [ 6.253642] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff235a504 [ 6.253947] R10: 0000000000000003 R11: 7463656e6e6f6320 R12: 0000000000000000 [ 6.254251] R13: 0000000000000000 R14: ffff88806c907c38 R15: 0000000000000000 [ 6.254549] FS: 0000000000000000(0000) GS:ffff8880d95bc000(0000) knlGS:0000000000000000 [ 6.254887] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.255140] CR2: 00007fc393e8ffc0 CR3: 0000000005252006 CR4: 0000000000770ef0 [ 6.255439] PKRU: 55555554 [ 6.255564] Call Trace: [ 6.255674] <IRQ> [ 6.255768] iscsicompletepdu+0x18bf/0x22a0 [ 6.256733] iscsicompletepdu+0x54/0xa0 [ 6.256905] iscsitcpdatarecvdone+0xf4/0x250 [ 6.257103] iscsitcprecvskb+0x31e/0xec0 [ 6.257680] iscsiswtcprecv+0x12f/0x390 [ 6.258061] tcpreadsock+0x1ab/0x810 [ 6.258853] iscsiswtcpdataready+0x18b/0x510 [ 6.259808] tcpdataqueue+0x1f13/0x4cd0 [ 6.260567] tcprcvestablished+0x8a5/0x3a00 [ 6.261931] tcpv4dorcv+0x449/0x960 [ 6.262269] tcpv4rcv+0x2245/0x3bc0

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

scsi: libiscsi: Validate the task named by a management response

iscsicompletepdu() fetches the task for five response types from one place and checks only that the index resolved:

case ISCSIOPLOGOUTRSP: case ISCSIOPLOGINRSP: case ISCSIOPTEXTRSP: case ISCSIOPSCSITMFUNCRSP: case ISCSIOPNOOPIN: task = iscsiitttotask(conn, hdr->itt); if (!task) return ISCSIERRBADITT;

iscsiitttotask() bounds the index against cmdsmax and looks at nothing else, so a target can name any slot in the pool, including one that has never been used. task->conn is then NULL, and both iscsinopoutrsp() and iscsicompletetask() dereference it. One unsolicited NOP-In is enough; a Text Response carrying the same ITT crashes in iscsicompletetask() instead.

Require the task to be in flight and not a SCSI command, the way iscsiitttoctask() does for the command opcodes.

[ 6.298634] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.298642] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.298652] CPU: 1 UID: 0 PID: 111 Comm: iscsistart Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.298654] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.298656] RIP: 0010:iscsinopoutrsp.constprop.0+0x46/0x160 [ 6.298691] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.298698] RSP: 0018:ffff88806c907be8 EFLAGS: 00010206 [ 6.298701] RAX: dffffc0000000000 RBX: ffff888006116800 RCX: 0000000000000020 [ 6.298702] RDX: 000000000000000c RSI: ffff88800525d578 RDI: 0000000000000060 [ 6.298703] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 6.298706] R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000 [ 6.298706] R13: 000000000000002e R14: ffff8880056eb440 R15: ffff888006116800 [ 6.298707] FS: 00007fc02d1c2740(0000) GS:ffff8880b29bc000(0000) knlGS:0000000000000000 [ 6.298710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.298711] CR2: 000055fe3b56ddf8 CR3: 00000000053b9004 CR4: 0000000000770ef0 [ 6.298712] PKRU: 55555554 [ 6.298713] Call Trace: [ 6.298714] <IRQ> [ 6.298714] iscsicompletepdu+0x13a8/0x22a0 [ 6.298758] iscsicompletepdu+0x54/0xa0 [ 6.298759] iscsitcphdrrecvdone+0x870/0x2c80 [ 6.298778] iscsitcprecvskb+0x31e/0xec0 [ 6.298800] iscsiswtcprecv+0x12f/0x390 [ 6.298804] tcpreadsock+0x1ab/0x810 [ 6.298812] iscsiswtcpdataready+0x18b/0x510 [ 6.298814] tcprcvestablished+0x1f56/0x3a00 [ 6.298842] tcpv4dorcv+0x449/0x960 [ 6.298847] tcpv4rcv+0x2245/0x3bc0

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

ppp: require CAPNETADMIN in target netns for unattached ioctls

/dev/ppp open is currently authorized against file->fcred->userns, while unattached administrative ioctls operate on current->nsproxy->netns.

As a result, a local unprivileged user can create a new user namespace with CLONENEWUSER, gain CAPNETADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace.

Require CAPNETADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls.

This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.

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

RDMA/rxe: Fix responder UAF on IBQPMAXDESTRDATOMIC modifyqp

rxeqpfromattr() handles IBQPMAXDESTRDATOMIC outside the IBQPSTATE path, so it holds no statelock and runs while the responder task rxereceiver() (recvtask on rxewq) is live. A modifyqp() setting only that attribute calls freerdatomicresources() then allocrdatomicresources(), swapping qp->resp.resources[] while rxeprepareres()/findresource() walk it; freerdatomicresources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxereceiver() (local DoS).

Drain recvtask around the swap with rxedisabletask()/rxeenabletask(), as rxeqpreset() already does when tearing this array down, re-enabling only after allocrdatomicresources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in freerdatomicresources(), like the rxeresp.c completion paths.

Reproduced under KASAN; the slab-use-after-free in rxereceiver() is gone.

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

RDMA/rxe: Fix OOB in freerdatomicresources()

freerdatomicresources() iterates using qp->attr.maxdestrdatomic. Updating maxdestrdatomic before freeing the old array can make the free path walk past the old allocation and trigger a slab out-of-bounds write catched by KASAN: ================================================================== BUG: KASAN: slab-out-of-bounds in freerdatomicresource drivers/infiniband/sw/rxe/rxeqp.c:180 [inline] BUG: KASAN: slab-out-of-bounds in freerdatomicresources drivers/infiniband/sw/rxe/rxeqp.c:171 [inline] BUG: KASAN: slab-out-of-bounds in freerdatomicresources drivers/infiniband/sw/rxe/rxeqp.c:163 [inline] BUG: KASAN: slab-out-of-bounds in rxeqpfromattr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxeqp.c:712 Write of size 4 at addr ffff88802b8dddb8 by task syz.3.451/11063

CPU: 0 UID: 0 PID: 11063 Comm: syz.3.451 Not tainted 7.1.0 #2 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x10e/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xf7/0x600 mm/kasan/report.c:482 kasanreport+0xe4/0x120 mm/kasan/report.c:595 freerdatomicresource drivers/infiniband/sw/rxe/rxeqp.c:180 [inline] freerdatomicresources drivers/infiniband/sw/rxe/rxeqp.c:171 [inline] freerdatomicresources drivers/infiniband/sw/rxe/rxeqp.c:163 [inline] rxeqpfromattr+0x1e88/0x2150 drivers/infiniband/sw/rxe/rxeqp.c:712 rxemodifyqp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxeverbs.c:623 ibsecuritymodifyqp+0x223/0xfa0 drivers/infiniband/core/security.c:625 ibmodifyqp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modifyqp+0x13ca/0x1940 drivers/infiniband/core/uverbscmd.c:1932 ibuverbsmodifyqp+0xcb/0x120 drivers/infiniband/core/uverbscmd.c:1958 ibuverbswrite+0xb86/0x1030 drivers/infiniband/core/uverbsmain.c:680 vfswrite+0x2aa/0x1070 fs/readwrite.c:686 ksyswrite+0x1f8/0x250 fs/readwrite.c:740 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x116/0x800 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fefc75a70cd Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fefc8495018 EFLAGS: 00000246 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fefc7835fa0 RCX: 00007fefc75a70cd RDX: 0000000000000078 RSI: 0000200000000240 RDI: 0000000000000007 RBP: 00007fefc764f10f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fefc7836038 R14: 00007fefc7835fa0 R15: 00007ffcf0586aa0 </TASK>

Allocated by task 11063: kasansavestack+0x33/0x60 mm/kasan/common.c:57 kasansavetrack+0x14/0x30 mm/kasan/common.c:78 poisonkmallocredzone mm/kasan/common.c:398 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:415 kasankmalloc include/linux/kasan.h:263 [inline] dokmallocnode mm/slub.c:5296 [inline] kmallocnoprof+0x32a/0x850 mm/slub.c:5308 kmallocnoprof include/linux/slab.h:954 [inline] kzallocnoprof include/linux/slab.h:1188 [inline] allocrdatomicresources drivers/infiniband/sw/rxe/rxeqp.c:155 [inline] rxeqpfromattr+0x3f8/0x2150 drivers/infiniband/sw/rxe/rxeqp.c:714 rxemodifyqp+0x1e2/0x530 drivers/infiniband/sw/rxe/rxeverbs.c:623 ibsecuritymodifyqp+0x223/0xfa0 drivers/infiniband/core/security.c:625 ibmodifyqp+0x333/0xec0 drivers/infiniband/core/verbs.c:1915 modifyqp+0x13ca/0x1940 drivers/infiniband/core/uverbscmd.c:1932 ibuverbsmodifyqp+0xcb/0x120 drivers/infiniband/core/uverbscmd.c:1958 ibuverbswrite+0xb86/0x1030 drivers/infiniband/core/uverbsma ---truncated---

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

Revert "wireguard: device: enable threaded NAPI"

This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream.

We have had three independent production user reports in combination with Cilium utilizing WireGuard as encryption underneath that k8s Pod E/W traffic to certain peer nodes fully stalled. The situation appears as follows:

- Occurs very rarely but at random times under heavy networking load. - Once the issue triggers the decryption side stops working completely for that WireGuard peer, other peers keep working fine. The stall happens also for newly initiated connections towards that particular WireGuard peer. - Only the decryption side is affected, never the encryption side. - Once it triggers, it never recovers and remains in this state, the CPU/mem on that node looks normal, no leak, busy loop or crash. - bpftrace on the affected system shows that wgprevqueueenqueue fails, thus the MAXQUEUEDPACKETS (1024 skbs!) for the peer's rxqueue is reached. - Also, bpftrace shows that wgpacketrxpoll for that peer is never called again after reaching this state for that peer. For other peers wgpacketrxpoll does get called normally. - Commit db9ae3b ("wireguard: device: enable threaded NAPI") switched WireGuard to threaded NAPI by default. The default has not been changed for triggering the issue, neither did CPU hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always return valid online CPU in wgcpumaskchooseonline()")). - The issue has been observed with stable kernels of v5.15 as well as v6.1. It was reported to us that v5.10 stable is working fine, and no report on v6.6 stable either (somewhat related discussion in [0] though). - In the WireGuard driver the only material difference between v5.10 stable and v5.15 stable is the switch to threaded NAPI by default.

[0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/

Breakdown of the problem:

1) skbs arriving for decryption are enqueued to the peer->rxqueue in wgpacketconsumedata via wgqueueenqueueperdeviceandpeer. 2) The latter only moves the skb into the MPSC peer queue if it does not surpass MAXQUEUEDPACKETS (1024) which is kept track in an atomic counter via wgprevqueueenqueue. 3) In case enqueueing was successful, the skb is also queued up in the device queue, round-robin picks a next online CPU, and schedules the decryption worker. 4) The wgpacketdecryptworker, once scheduled, picks these up from the queue, decrypts the packets and once done calls into wgqueueenqueueperpeerrx. 5) The latter updates the state to PACKETSTATECRYPTED on success and calls napischedule on the per peer->napi instance. 6) NAPI then polls via wgpacketrxpoll. wgprevqueuepeek checks on the peer->rxqueue. It will wgprevqueuedequeue if the queue->peeked skb was not cached yet, or just return the latter otherwise. (wgprevqueuedroppeeked later clears the cache.) 7) From an ordering perspective, the peer->rxqueue has skbs in order while the device queue with the per-CPU worker threads from a global ordering PoV can finish the decryption and signal the skb PACKETSTATECRYPTED out of order. 8) A situation can be observed that the first packet coming in will be stuck waiting for the decryption worker to be scheduled for a longer time when the system is under pressure. 9) While this is the case, the other CPUs in the meantime finish decryption and call into napischedule. 10) Now in wgpacketrxpoll it picks up the first in-order skb from the peer->rxqueue and sees that its state is still PACKETSTATEUNCRYPTED. The NAPI poll routine then exits e ---truncated---

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

scsi: libiscsi: Validate the task named by a management response

iscsicompletepdu() fetches the task for five response types from one place and checks only that the index resolved:

case ISCSIOPLOGOUTRSP: case ISCSIOPLOGINRSP: case ISCSIOPTEXTRSP: case ISCSIOPSCSITMFUNCRSP: case ISCSIOPNOOPIN: task = iscsiitttotask(conn, hdr->itt); if (!task) return ISCSIERRBADITT;

iscsiitttotask() bounds the index against cmdsmax and looks at nothing else, so a target can name any slot in the pool, including one that has never been used. task->conn is then NULL, and both iscsinopoutrsp() and iscsicompletetask() dereference it. One unsolicited NOP-In is enough; a Text Response carrying the same ITT crashes in iscsicompletetask() instead.

Require the task to be in flight and not a SCSI command, the way iscsiitttoctask() does for the command opcodes.

[ 6.298634] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN NOPTI [ 6.298642] KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067] [ 6.298652] CPU: 1 UID: 0 PID: 111 Comm: iscsistart Not tainted 7.2.0-rc5-ISCSI1-gf5098b6bae76 #1 PREEMPT(lazy) [ 6.298654] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 6.298656] RIP: 0010:iscsinopoutrsp.constprop.0+0x46/0x160 [ 6.298691] Code: c1 ea 03 48 83 ec 08 80 3c 02 00 0f 85 f5 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 58 48 8d 7d 60 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 c0 00 00 00 48 8b 45 60 48 39 c3 74 50 48 b8 00 [ 6.298698] RSP: 0018:ffff88806c907be8 EFLAGS: 00010206 [ 6.298701] RAX: dffffc0000000000 RBX: ffff888006116800 RCX: 0000000000000020 [ 6.298702] RDX: 000000000000000c RSI: ffff88800525d578 RDI: 0000000000000060 [ 6.298703] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 6.298706] R10: 0000000000000020 R11: 0000000000000000 R12: 0000000000000000 [ 6.298706] R13: 000000000000002e R14: ffff8880056eb440 R15: ffff888006116800 [ 6.298707] FS: 00007fc02d1c2740(0000) GS:ffff8880b29bc000(0000) knlGS:0000000000000000 [ 6.298710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.298711] CR2: 000055fe3b56ddf8 CR3: 00000000053b9004 CR4: 0000000000770ef0 [ 6.298712] PKRU: 55555554 [ 6.298713] Call Trace: [ 6.298714] <IRQ> [ 6.298714] iscsicompletepdu+0x13a8/0x22a0 [ 6.298758] iscsicompletepdu+0x54/0xa0 [ 6.298759] iscsitcphdrrecvdone+0x870/0x2c80 [ 6.298778] iscsitcprecvskb+0x31e/0xec0 [ 6.298800] iscsiswtcprecv+0x12f/0x390 [ 6.298804] tcpreadsock+0x1ab/0x810 [ 6.298812] iscsiswtcpdataready+0x18b/0x510 [ 6.298814] tcprcvestablished+0x1f56/0x3a00 [ 6.298842] tcpv4dorcv+0x449/0x960 [ 6.298847] tcpv4rcv+0x2245/0x3bc0

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

ALSA: seq: midi: Serialize input teardown with eventinput

sndmidiinputevent() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in sndrawmidiinputtrigger():

sndrawmidiinputtrigger(up=0) sndmidiinputevent() -> sndrawmidikernelread() -> sndrawmidiinputtrigger(up=1) -> cancelworksync()

which ends with the underlying device being active unexpectedly.

When this is called from closesubstream(), further input can re-trigger the input event leaving it running after rawmidireleasepriv() has set rfile->rmidi to NULL which leads to:

Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 Call trace: sndmidiinputevent+0x3c/0x134 [sndseqmidi] (P) sndrawmidiinputeventwork+0x1c/0x2c processonework+0x150/0x3a4 workerthread+0x190/0x318

Apply a similar approach to commit ef7607ab1c8ad ("ALSA: seq: midi: Serialize output teardown with eventinput") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1].

With this change in place, midisynthunsubscribe() clears the input file so sndmidiinputevent() will not re-trigger the stream and will be quiesced by the cancelworksync() in sndrawmidiinputtrigger().

[1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/

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

ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF

sndpcmhwparams() and sndpcmhwfree() guard buffer reallocation with an mmapcount check performed under the PCM stream lock, but the lock is released long before the buffer is actually freed: sndpcmsyncstop(), constraint refinement and dofreepages() all happen in between. sndpcmmmapdata(), on the other hand, takes no lock at all: it validates against the old buffer's state and dmabytes, remaps its pages into the VMA, and only then increments mmapcount.

A concurrent mmap() can therefore slip in between the check and the free. remappfnrange() installs writable PTEs for the old buffer's pages without taking page references, and the subsequent dofreepages() returns those pages to the page allocator while the VMA still maps them. This leaves a stale, writable mapping of freed pages: a page-level use-after-free that can be leveraged for local privilege escalation.

Make sndpcmmmapdata() participate in the buffer-access scheme introduced for hwparams/hwfree: acquire runtime->bufferaccessing before validating and remapping, and release it afterwards. Buffer reallocation already fails with -EBUSY while accessors are active, and the mmap side now fails with -EBUSY while a reallocation is in progress, so the validate/remap sequence and the check/free sequence can no longer interleave.

A reproducer that turns this race into a stale writable mapping of the freed DMA buffer pages is available on request.

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

s390/qeth: validate user buffer length in SNMP and ARP query ioctls

qethsnmpcommand() and qethl3arpquery() allocate a buffer sized by a user-supplied length (udatalen) without checking a lower bound, then set udataoffset to a fixed non-zero value and pass both to a reply callback. The callback bounds-checks the copy with

if ((udatalen - udataoffset) < len)

Both fields are u32, so a udatalen smaller than udataoffset makes the subtraction wrap and the check pass, and the following memcpy() writes past the allocation. A udatalen of 0 also yields ZEROSIZEPTR from kzalloc(), which the existing NULL check does not catch.

Reject buffers smaller than udataoffset before allocating, so the callback subtraction can no longer underflow.

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

net/smc: fix use-after-free of the LLC qentry in smcllcsrvaddlink()

smcllcsrvaddlink() keeps addllc pointing into the queue entry:

addllc = &qentry->msg.addlink; smcllc.c:1482 ... smcllcsaveaddlinkinfo(linknew, addllc); smcllc.c:1494 smcllcflowqentrydel(&lgr->llcflowlcl); smcllc.c:1495 ... u8 llcmsg = smclinksharedv2rxbuf(link) ? (u8 )lgr->wrrxbufv2 : (u8 )addllc; smcllc.c:1504 smcllcsaveaddlinkrkeys(link, linknew, llcmsg); smcllc.c:1506

smcllcflowqentrydel() kfree()s the entry, so on a link without a shared v2 receive buffer the pointer handed to smcllcsaveaddlinkrkeys() is already freed. Before the Fixes: commit that branch always used lgr->wrrxbufv2 and addllc was not used after the free.

Reproduced on an unpatched tree over rxe, with KASAN, kasanmultishot and a link forced to maxrecvsge == 1: the entry is freed and read by the same call, and the freeing frame is smcllcsrvaddlink() itself.

[ 2.523161] BUG: KASAN: slab-use-after-free in smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.523499] Read of size 2 at addr ffff8880052194de by task kworker/0:1/11 [ 2.523789] [ 2.523862] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 7.2.0-rc5-p0-g2c9dd296545d #35 PREEMPT(lazy) [ 2.523865] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, archcaps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 2.523866] Workqueue: smchswq smclistenwork [ 2.523869] Call Trace: [ 2.523870] <TASK> [ 2.523871] dumpstacklvl+0x53/0x70 [ 2.523872] printreport+0xd0/0x630 [ 2.523874] ? pfxrawspinlockirqsave+0x10/0x10 [ 2.523876] ? smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.523878] kasanreport+0xce/0x100 [ 2.523879] ? smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.523881] smcllcsaveaddlinkrkeys+0x333/0x350 [ 2.523883] ? smcrbufreglgr+0x2a4/0x660 [ 2.523885] smcllcsrvaddlink+0xaa2/0x1e50 [ 2.523888] ? printk+0xba/0xf0 [ 2.523897] ? pfxsmcllcsrvaddlink+0x10/0x10 [ 2.523899] ? downwrite+0xb0/0x130 [ 2.523903] ? pfxdownwrite+0x10/0x10 [ 2.523905] smclistenwork+0x489e/0x4d00 [ 2.523907] ? kmemcachefree+0x1c6/0x3a0 [ 2.523911] ? pfxsmclistenwork+0x10/0x10 [ 2.523913] ? releasesock+0x148/0x1d0 [ 2.523915] ? smctcplistenwork+0xb4f/0xfc0 [ 2.523917] ? rawspinlockirq+0x80/0xe0 [ 2.523918] ? pfxrawspinlockirq+0x10/0x10 [ 2.523920] processonework+0x633/0x1030 [ 2.523922] ? assignwork+0x11d/0x370 [ 2.523924] workerthread+0x45b/0xd10 [ 2.523926] ? pfxworkerthread+0x10/0x10 [ 2.523928] ? pfxworkerthread+0x10/0x10 [ 2.523929] kthread+0x2c6/0x3b0 [ 2.523931] ? recalcsigpending+0x15c/0x1e0 [ 2.523934] ? pfxkthread+0x10/0x10 [ 2.523935] retfromfork+0x36e/0x5a0 [ 2.523937] ? pfxretfromfork+0x10/0x10 [ 2.523938] ? switchto+0x572/0xdd0 [ 2.523943] ? pfxkthread+0x10/0x10 [ 2.523944] retfromforkasm+0x1a/0x30 [ 2.523947] </TASK> [ 2.523948] [ 2.531253] Allocated by task 48: [ 2.531399] kasansavestack+0x33/0x60 [ 2.531570] kasansavetrack+0x14/0x30 [ 2.531737] kasankmalloc+0x8f/0xa0 [ 2.531905] kmalloccachenoprof+0x158/0x370 [ 2.532100] smcllcenqueue+0x72/0x560 [ 2.532268] smcwrrxtaskletfn+0x474/0xa80 [ 2.532491] taskletactioncommon+0x20f/0x8a0 [ 2.532714] handlesoftirqs+0x18e/0x590 [ 2.532886] dosoftirq+0x3b/0x60 [ 2.533036] localbhenableip+0x61/0x70 [ 2.533221] allocskb+0x732/0x890 [ 2.533384] rxeinitpacket+0x16b/0x4f0 [ 2.533567] prepareackpacket+0xb8/0x830 [ 2.533760] rxereceiver+0x495/0x96e0 [ 2.533933] dowork+0x144/0x470 [ 2 ---truncated---

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

net/sched: actct: fix helper UAF due to extensions realloc

While calling the helpers, a raw pointer to the extensions area is wired into expectations list:

-> nfcthelper() -> helper->help() -> nfctexpectrelatedreport() -> nfctexpectinsert() -> hlistaddheadrcu(&exp->lnode, &masterhelp->expectations)

In case the connection is not confirmed yet, more extensions can be added afterwards with extadd() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the expectation.

Make sure that helpers are called at the end after all the other extensions are already added.

Note that the helper rejection now leaves the mark and labels set, but that's not different from how the NAT was handled before or how the mark and the labels were handled on confirmation failure. And there are no atomicity guarantees provided by the API anyway.

ALSA: ua101: reject mismatched capture/playback packet sizes

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

net/smc: protect clcsock lifetime in smcgetname

smcgetname() dereferences smc->clcsock without holding clcsockreleaselock. Link-group termination can release the CLC socket through smccloseactiveabort() while the SMC socket is still open, for example after shutdown(SHUTWR).

A getsockname() caller can load smc->clcsock, then the termination worker can clear the pointer and call sockrelease() before the caller accesses clcsock->ops or invokes getname(). This causes a use-after-free; if the worker clears the pointer before the load, it causes a NULL dereference. The syscall's file reference keeps the SMC socket alive but does not prevent asynchronous release of its CLC socket.

KASAN reported the following with test-only timing instrumentation:

BUG: KASAN: slab-use-after-free in smcgetname+0x19e/0x1b0 Read of size 8 at addr ffff888109abb4e0 by task poc/103 Call Trace: smcgetname+0x19e/0x1b0 dogetsockname+0xe5/0x170 sysgetsockname+0x8c/0x100

Allocated by task 95: sockallocinode+0x1e/0x280 sockalloc+0x3d/0x240 sockcreate+0x7e/0x430 smccreate+0x121/0x240

Freed by task 0: kmemcachefree+0xcc/0x340 rcucore+0x50a/0x1850

Last potentially related work creation: evict+0x446/0x6c0 smcclcsockrelease+0xa8/0xd0 smccloseactiveabort+0x26a/0x3a0 smclgrterminate.part.0+0x137/0x2e0

Hold clcsockreleaselock across the pointer check and the getname() callback to serialize with smcclcsockrelease(). Return -EBADF if the CLC socket has already been released, preserving the existing peer state check and the callback's return value otherwise.

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

powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak

In paprphyattestcreatehandle(), the params->cmd.length is not validated before use, which can result in a buffer overlow. Check it and return -EINVAL if it is either 0 or exceeds sizeof(params->cmd).

Also, params is freed on the success path but not error. Free it on errors after memory allocation. And free it on negative fd.

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

sctp: stop processing a packet once its association is deleted

sctpendpointbhrcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference.

A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctpsfdo92final(), so the association and its transports are freed.

The endpoint loop has no counterpart to the asoc->base.dead check in sctpassocbhrcv(). The next chunk writes to lasttimeheard in the freed transport and is then passed to sctpdosm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context.

The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctpinqfree() releases the chunk on the association receive path.

sctpsfdo524dupcook() issues SCTPCMDDELETETCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.

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

USB: serial: ioti: fix heap overflow in getmanufinfo()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanufdescriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2CSIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling readrom().

[ johan: amend commit message; also check for short descriptors ]

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

sctp: avoid authenable sysctl UAF during netns teardown

procsctpdoauth() updates the SCTP control socket after changing net.sctp.authenable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down.

SCTP previously registered its per-net sysctls from sctpdefaultsinit(), while the control socket is created later from sctpctrlsockinit(). This exposed a window during initialization where authenable was writable before net->sctp.ctlsock existed, and a teardown window where authenable stayed writable after inetctlsockdestroy() had released the control socket.

Move the per-net SCTP sysctl registration into sctpctrlsockinit() after sctpctlsockinit() succeeds, and unregister the sysctl table before destroying the control socket in sctpctrlsockexit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path.

Make sctpsysctlnetunregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.

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

s390/zcrypt: Validate length for CCA ECC private key requests

ccaecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.

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

nvmet-tcp: check return value of nvmettcpsetqueuesock

The return value of nvmettcpsetqueuesock() is currently ignored in nvmettcptlshandshakedone(). If it fails (e.g., due to the socket not being in TCPESTABLISHED state), the socket callbacks will not be properly set, leading to queue and socket leakage.

Fix this by capturing the return value and calling nvmettcpschedulereleasequeue() on failure to ensure proper cleanup.

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

sctp: clear newtransport when removing a peer

sctpprocessasconfparam() stores a newly added peer transport in asoc->newtransport. After all parameters in the ASCONF chunk have been processed, sctpsfdoasconf() uses this pointer to send a HEARTBEAT to the new transport.

An authenticated ASCONF from a remote SCTP peer can add a transport and remove it again with a wildcard DEL-IP parameter in the same chunk. The wildcard deletion preserves the transport on which the ASCONF arrived, but removes the newly added transport through sctpassocdelnonprimarypeers(). The removal does not clear asoc->newtransport, leaving it pointing to the removed transport.

sctpsfdoasconf() then creates a HEARTBEAT whose chunk->transport points to the removed transport without holding a transport reference. During local address replacement, srcoutofasocok keeps this HEARTBEAT on controlchunklist. After the transport is freed by RCU, a successful ASCONFACK for the replacement address releases the queued HEARTBEAT and sctpoutqselecttransport() reads the freed transport's state.

The issue was found during a static audit of SCTP objects. With an authenticated peer, the reproducer triggered the same KASAN report in 2 of 2 unpatched runs on a KASAN-enabled netdev/main kernel:

BUG: KASAN: slab-use-after-free in sctpoutqselecttransport Read of size 4 at addr ffff88800b9bd95c by task python3/197

Call Trace: sctpoutqselecttransport+0x549/0x8b0 [sctp] sctpoutqflush+0x306/0x2c60 [sctp] sctptransportimmediatertx+0xaf/0x260 [sctp] sctpprocessasconfack+0xa48/0xf70 [sctp]

Allocated by task 197: sctptransportnew+0x68/0x650 [sctp] sctpassocaddpeer+0x258/0x12a0 [sctp] sctpprocessasconf+0x5e9/0x1090 [sctp]

Last potentially related work creation: callrcucommon.constprop.0+0x77/0xb70 sctpassocdelnonprimarypeers+0x7c/0xd0 [sctp] sctpprocessasconf+0xd9c/0x1090 [sctp]

The first invalid access was a four-byte read of transport->state at net/sctp/outqueue.c:833. The same reproducer completed the full authenticated ASCONF and local-address replacement sequence with this change without a KASAN report or oops.

Clear newtransport when its peer is removed, before it can be used to create the HEARTBEAT.

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

s390/zcrypt: Validate length for CCA ECC private key requests

ccaecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.

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

s390/zcrypt: Validate length for CCA AES cipher key requests

ccacipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.

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

net/iucv: fix use-after-free of a severed iucvpath

afiucv queues not-yet-received message notifications on iucv->messageq, each holding a raw pointer to the connection's iucvpath. When the peer severs the connection, iucvseverpath() frees that path with iucvpathfree() but leaves the notifications queued. A later recvmsg() drains messageq via iucvprocessmessageq() and hands the stale path to messagereceive() -- a use-after-free of the freed iucvpath.

Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.