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

net/sched: actapi: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.

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

tun: free page on buildskb failure in tunxdpone()

When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each buildskb() failure in a batch leaks one page-frag chunk.

Free the page before taking the error path, matching the putpage() the other error exits of tunxdpone() already perform.

Bluetooth: hciconn: fix potential UAF in createbigsync

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

of: unittest: fix use-after-free in testdrvprobe()

The function testdrvprobe() retrieves the devicenode from the PCI device, applies an overlay, and then immediately calls ofnodeput(dn). This releases the reference held by the PCI core, potentially freeing the node if the reference count drops to zero. Later, the same freed pointer 'dn' is passed to ofplatformdefaultpopulate(), leading to a use-after-free.

The reference to pdev->dev.ofnode is owned by the device model and should not be released by the driver. Remove the erroneous ofnodeput() to prevent premature freeing.

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

hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read

The q54sj108a2debugfsread function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'datachar' as the source.

Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2CSMBUSBLOCKMAX + 2), this writes 30 bytes past the end of the buffer onto the stack.

Additionally, the arguments were swapped: it was reading from the zero-initialized 'datachar' and writing to 'data', resulting in all-zero output regardless of the actual I2C read.

Fix this by: 1. Expanding 'datachar' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simplereadfrombuffer call.

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

smb: client: fix in-place encryption corruption in SMB2write()

SMB2write() places write payload in iov[1..n] as part of rqiov. smb3inittransformrq() pointer-shares rqiov, so cryptmessage() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption.

The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data.

This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rqiter which gets deep-copied.

Fix by moving the write payload into rqiter via ioviterkvec(), so smb3inittransformrq() deep-copies it before encryption.

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

usb: gadget: fuac1legacy: validate control request size

faudiocomplete() copies req->length bytes into a 4-byte stack variable:

u32 data = 0; memcpy(&data, req->buf, req->length);

req->length is derived from the host-controlled USB request path, which can lead to a stack out-of-bounds write.

Validate req->actual against the expected payload size for the supported control selectors and decode only the expected amount of data.

This avoids copying a host-influenced length into a fixed-size stack object.

On a system exposing an NVMe/TCP target, a remote client can trigger a kernel panic by sending a CONNECT command for an I/O queue with a bogus or stale CNTLID.

An attacker with network access to the NVMe/TCP target can trigger an unauthenticated Denial of Service condition on the affected machine.

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

ksmbd: fix buffer validation by including null terminator size in EA length

The smb2setea function, which handles Extended Attributes (EA), was performing buffer validation checks that incorrectly omitted the size of the null terminating character (+1 byte) for EA Name. This patch fixes the issue by explicitly adding '+ 1' to EaNameLength where the null terminator is expected to be present in the buffer, ensuring the validation accurately reflects the total required buffer size.

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

dax: Fix daxmappingrelease() use after free

A CONFIGDEBUGKOBJECTRELEASE test of removing a device-dax region provider (like modprobe -r daxhmem) yields:

kobject: 'mapping0' (ffff93eb460e8800): kobjectrelease, parent 0000000000000000 (delayed 2000) [..] DEBUGLOCKSWARNON(1) WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 lockacquire+0x9fc/0x2260 [..] RIP: 0010:lockacquire+0x9fc/0x2260 [..] Call Trace: <TASK> [..] lockacquire+0xd4/0x2c0 ? idafree+0x62/0x130 rawspinlockirqsave+0x47/0x70 ? idafree+0x62/0x130 idafree+0x62/0x130 daxmappingrelease+0x1f/0x30 devicerelease+0x36/0x90 kobjectdelayedcleanup+0x46/0x150

Due to attempting idafree() on an ida object that has already been freed. Devices typically only hold a reference on their parent while registered. If a child needs a parent object to complete its release it needs to hold a reference that it drops from its release callback. Arrange for a daxmapping to pin its parent devdax instance until daxmappingrelease().

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

ublk: fail to start device if queue setup is interrupted

In ublkctrlstartdev(), if waitforcompletioninterruptible() is interrupted by signal, queues aren't setup successfully yet, so we have to fail UBLKCMDSTARTDEV, otherwise kernel oops can be triggered.

Reported by German when working on qemu-storage-deamon which requires single thread ublk daemon.

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

f2fs: fix kernel crash due to null io->bio

We should return when io->bio is null before doing anything. Otherwise, panic.

BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:submitmergedwritecond+0x164/0x240 [f2fs] Call Trace: <TASK> f2fssubmitmergedwrite+0x1d/0x30 [f2fs] commitcheckpoint+0x110/0x1e0 [f2fs] f2fswritecheckpoint+0x9f7/0xf00 [f2fs] ? pfxissuecheckpointthread+0x10/0x10 [f2fs] checkpointandcompletereqs+0x84/0x190 [f2fs] ? preemptcountadd+0x82/0xc0 ? pfxissuecheckpointthread+0x10/0x10 [f2fs] issuecheckpointthread+0x4c/0xf0 [f2fs] ? pfxautoremovewakefunction+0x10/0x10 kthread+0xff/0x130 ? pfxkthread+0x10/0x10 retfromfork+0x2c/0x50 </TASK>

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

drm/tests: helpers: Avoid a driver uaf

when using drmkunithelperallocdrmdevice() the driver may be dereferenced by device-managed resources up until the device is freed, which is typically later than the kunit-managed resource code frees it. Fix this by simply make the driver device-managed as well.

In short, the sequence leading to the UAF is as follows:

INIT: Code allocates a struct device as a kunit-managed resource. Code allocates a drm driver as a kunit-managed resource. Code allocates a drm device as a device-managed resource.

EXIT: Kunit resource cleanup frees the drm driver Kunit resource cleanup puts the struct device, which starts a device-managed resource cleanup device-managed cleanup calls drmdevput() drmdevput() dereferences the (now freed) drm driver -> Boom.

Related KASAN message: [55272.551542] ================================================================== [55272.551551] BUG: KASAN: slab-use-after-free in drmdevput.part.0+0xd4/0xe0 [drm] [55272.551603] Read of size 8 at addr ffff888127502828 by task kunittrycatch/10353

[55272.551612] CPU: 4 PID: 10353 Comm: kunittrycatch Tainted: G U N 6.5.0-rc7+ #155 [55272.551620] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [55272.551626] Call Trace: [55272.551629] <TASK> [55272.551633] dumpstacklvl+0x57/0x90 [55272.551639] printreport+0xcf/0x630 [55272.551645] ? rawspinlockirqsave+0x5f/0x70 [55272.551652] ? drmdevput.part.0+0xd4/0xe0 [drm] [55272.551694] kasanreport+0xd7/0x110 [55272.551699] ? drmdevput.part.0+0xd4/0xe0 [drm] [55272.551742] drmdevput.part.0+0xd4/0xe0 [drm] [55272.551783] devresreleaseall+0x15d/0x1f0 [55272.551790] ? pfxdevresreleaseall+0x10/0x10 [55272.551797] deviceunbindcleanup+0x16/0x1a0 [55272.551802] devicereleasedriverinternal+0x3e5/0x540 [55272.551808] ? kobjectput+0x5d/0x4b0 [55272.551814] busremovedevice+0x1f1/0x3f0 [55272.551819] devicedel+0x342/0x910 [55272.551826] ? pfxdevicedel+0x10/0x10 [55272.551830] ? lockrelease+0x339/0x5e0 [55272.551836] ? kunitremoveresource+0x128/0x290 [kunit] [55272.551845] ? pfxlockrelease+0x10/0x10 [55272.551851] platformdevicedel.part.0+0x1f/0x1e0 [55272.551856] ? rawspinunlockirqrestore+0x30/0x60 [55272.551863] kunitremoveresource+0x195/0x290 [kunit] [55272.551871] ? rawspinunlockirqrestore+0x30/0x60 [55272.551877] kunitcleanup+0x78/0x120 [kunit] [55272.551885] ? kthreadparkme+0xc1/0x1f0 [55272.551891] ? pfxkunittryruncasecleanup+0x10/0x10 [kunit] [55272.551900] ? pfxkunitgenericrunthreadfnadapter+0x10/0x10 [kunit] [55272.551909] kunitgenericrunthreadfnadapter+0x4a/0x90 [kunit] [55272.551919] kthread+0x2e7/0x3c0 [55272.551924] ? pfxkthread+0x10/0x10 [55272.551929] retfromfork+0x2d/0x70 [55272.551935] ? pfxkthread+0x10/0x10 [55272.551940] retfromforkasm+0x1b/0x30 [55272.551948] </TASK>

[55272.551953] Allocated by task 10351: [55272.551956] kasansavestack+0x1c/0x40 [55272.551962] kasansettrack+0x21/0x30 [55272.551966] kasankmalloc+0x8b/0x90 [55272.551970] kmalloc+0x5e/0x160 [55272.551976] kunitkmallocarray+0x1c/0x50 [kunit] [55272.551984] drmexectestinit+0xfa/0x2c0 [drmexectest] [55272.551991] kunittryruncase+0xdd/0x250 [kunit] [55272.551999] kunitgenericrunthreadfnadapter+0x4a/0x90 [kunit] [55272.552008] kthread+0x2e7/0x3c0 [55272.552012] retfromfork+0x2d/0x70 [55272.552017] retfromforkasm+0x1b/0x30

[55272.552024] Freed by task 10353: [55272.552027] kasansavestack+0x1c/0x40 [55272.552032] kasansettrack+0x21/0x30 [55272.552036] kasansavefreeinfo+0x27/0x40 [55272.552041] kasanslabfree+0x106/0x180 [55272.552046] slabfreefreelisthook+0xb3/0x160 [55272.552051] kmemcachefree+0xb2/0x290 [55272.552056] kunitremoveresource+0x195/0x290 [kunit] [55272.552064] kunitcleanup+0x7 ---truncated---

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

mtd: core: add missing ofnodeget() in dynamic partitions code

This fixes unbalanced ofnodeput(): [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand [ 1.085116] Creating 6 MTD partitions on "gpmi-nand": [ 1.090181] 0x000000000000-0x000008000000 : "nandboot" [ 1.096952] 0x000008000000-0x000009000000 : "nandfit" [ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel" [ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb" [ 1.115525] ------------[ cut here ]------------ [ 1.120141] refcountt: addition on 0; use-after-free. [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcountwarnsaturate+0xdc/0x148 [ 1.133528] Modules linked in: [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7 [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT) [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158965] pc : refcountwarnsaturate+0xdc/0x148 [ 1.163760] lr : refcountwarnsaturate+0xdc/0x148 [ 1.168556] sp : ffff800009ddb080 [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002 [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05 [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000 [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004 [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003 [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00 [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000 [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a [ 1.243365] Call trace: [ 1.245806] refcountwarnsaturate+0xdc/0x148 [ 1.250253] kobjectget+0x98/0x9c [ 1.253658] ofnodeget+0x20/0x34 [ 1.257072] offwnodeget+0x3c/0x54 [ 1.260652] fwnodegetnthparent+0xd8/0xf4 [ 1.264926] fwnodefullnamestring+0x3c/0xb4 [ 1.269373] devicenodestring+0x498/0x5b4 [ 1.273561] pointer+0x41c/0x5d0 [ 1.276793] vsnprintf+0x4d8/0x694 [ 1.280198] vprintkstore+0x164/0x528 [ 1.283951] vprintkemit+0x98/0x164 [ 1.287530] vprintkdefault+0x44/0x6c [ 1.291284] vprintk+0xf0/0x134 [ 1.294428] printk+0x54/0x7c [ 1.297486] ofnoderelease+0xe8/0x128 [ 1.301326] kobjectput+0x98/0xfc [ 1.304732] ofnodeput+0x1c/0x28 [ 1.308137] addmtddevice+0x484/0x6d4 [ 1.311977] addmtdpartitions+0xf0/0x1d0 [ 1.316078] parsemtdpartitions+0x45c/0x518 [ 1.320439] mtddeviceparseregister+0xb0/0x274 [ 1.325147] gpminandprobe+0x51c/0x650 [ 1.329074] platformprobe+0xa8/0xd0 [ 1.332740] reallyprobe+0x130/0x334 [ 1.336406] driverprobedevice+0xb4/0xe0 [ 1.340681] driverprobedevice+0x3c/0x1f8 [ 1.344869] driverattach+0xdc/0x1a4 [ 1.348708] busforeachdev+0x80/0xcc [ 1.352548] driverattach+0x24/0x30 [ 1.356127] busadddriver+0x108/0x1f4 [ 1.359967] driverregister+0x78/0x114 [ 1.363807] platformdriverregister+0x24/0x30 [ 1.368515] gpminanddriverinit+0x1c/0x28 [ 1.372798] dooneinitcall+0xbc/0x238 [ 1.376638] doinitcalllevel+0x94/0xb4 [ 1.380565] doinitcalls+0x54/0x94 [ 1.384058] dobasicsetup+0x1c/0x28 [ 1.387724] kernelinitfreeable+0x110/0x188 [ 1.392084] kernelinit+0x20/0x1a0 [ 1.395578] retfromfork+0x10/0x20 [ 1.399157] ---[ end trace 0000000000000000 ]--- [ 1.403782] ------------[ cut here ]------------

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

cpufreq: qcom: fix writes in read-only memory region

This commit fixes a kernel oops because of a write in some read-only memory:

[ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcomcpufreqmsm8939nameversion+0xb4/0x190 [ 9.284869] qcomcpufreqprobe+0xc8/0x39c ..snip..

The following line defines a pointer that point to a char buffer stored in read-only memory:

char pvsname = "speedXX-pvsXX-vXX";

This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcomcpufreqkraitnameversion function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops:

snprintf(pvsname, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvsver);

To fix this issue, we instead store the template name onto the stack by using the following syntax:

char pvsnamebuffer[] = "speedXX-pvsXX-vXX";

Because the pvsname needs to be able to be assigned to NULL, the template buffer is stored in the pvsnamebuffer and not under the pvsname variable.

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

usb: core: config: Prevent OOB read in SS endpoint companion parsing

usbparsessendpointcompanion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.

Fix this up by checking the size first before looking at any of the fields in the descriptor.

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

virtio-net: ensure the received length does not exceed allocated size

In xdplinearizepage, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.

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

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlennotify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:

tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole

echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.

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

powerpc/bpf: fix JIT code size calculation of bpf trampoline

archbpftrampolinesize() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. The total number of instructions emitted for BPF trampoline JIT code depends on where the final image is located. So, the size arrived at with the dummy pass in archbpftrampolinesize() can vary from the actual size needed in archpreparebpftrampoline(). When the instructions accounted in archbpftrampolinesize() is less than the number of instructions emitted during the actual JIT compile of the trampoline, the below warning is produced:

WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpfjitcomp.c:981 archpreparebpftrampoline.isra.0+0xd2c/0xdcc

which is:

/ Make sure the trampoline generation logic doesn't overflow / if (image && WARNONONCE(&image[ctx->idx] > (u32 )rwimageend - BPFINSNSAFETY)) {

So, during the dummy pass, instead of providing some arbitrary image location, account for maximum possible instructions if and when there is a dependency with image location for JIT'ing.

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

firmware: csdsp: Fix OOB memory read access in KUnit test (ctl cache)

KASAN reported out of bounds access - csdspctlcacheinitmultipleoffsets(). The code uses mockcoefftemplate.lengthbytes (4 bytes) for register value allocations. But later, this length is set to 8 bytes which causes test code failures.

As fix, just remove the lenght override, keeping the original value 4 for all operations.

calipso: Fix null-ptr-deref in calipsoreq{set,del}attr().

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

schhfsc: make hfscqlennotify() idempotent

hfscqlennotify() is not idempotent either and not friendly to its callers, like fqcodeldequeue(). Let's make it idempotent to ease qdisctreereducebacklog() callers' life:

1. updatevf() decreases cl->clnactive, so we can check whether it is non-zero before calling it.

2. eltreeremove() always removes RB node cl->elnode, but we can use RBEMPTYNODE() + RBCLEARNODE() to make it safe.

coresight: prevent deactivate active config while enabling the config

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

net: fix udp gso skbsegment after pull from fraglist

Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from fraglist") detected invalid geometry in fraglist skbs and redirects them from skbsegmentlist to more robust skbsegment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skbsegment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust.

If only part of the fraglist payload is pulled into headskb, it will always cause exception when splitting skbs by skbsegment. For detailed call stack information, see below.

Valid SKBGSOFRAGLIST skbs - consist of two or more segments - the headskb holds the protocol headers plus first gsosize - one or more fraglist skbs hold exactly one segment - all but the last must be gsosize

Optional datapath hooks such as NAT and BPF (bpfskbpulldata) can modify fraglist skbs, breaking these invariants.

In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes.

The skbs no longer meets the above SKBGSOFRAGLIST conditions because payload was pulled into headskb, it needs to be linearized before pass to regular skbsegment.

skbsegment+0xcd0/0xd14 udpgsosegment+0x334/0x5f4 udp4ufofragment+0x118/0x15c inetgsosegment+0x164/0x338 skbmacgsosegment+0xc4/0x13c skbgsosegment+0xc4/0x124 validatexmitskb+0x9c/0x2c0 validatexmitskblist+0x4c/0x80 schdirectxmit+0x70/0x404 devqueuexmit+0x64c/0xe5c neighresolveoutput+0x178/0x1c4 ipfinishoutput2+0x37c/0x47c ipfinishoutput+0x194/0x240 ipfinishoutput+0x20/0xf4 ipoutput+0x100/0x1a0 NFHOOK+0xc4/0x16c ipforward+0x314/0x32c iprcv+0x90/0x118 netifreceiveskb+0x74/0x124 processbacklog+0xe8/0x1a4 napipoll+0x5c/0x1f8 netrxaction+0x154/0x314 handlesoftirqs+0x154/0x4b8

[118.376811] [C201134] rxq0pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0pus: [name:mrdump&]PHYSOFFSET: 0x40000000 [118.470827] [C201134] rxq0pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0pus: [name:mrdump&]pc : [0xffffffd79598aefc] skbsegment+0xcd0/0xd14 [118.470900] [C201134] rxq0pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skbsegment+0x3bc/0xd14 [118.470928] [C201134] rxq0pus: [name:mrdump&]sp : ffffffc008013770

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

espintcp: remove encap socket caching to avoid reference leak

The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.

The reference chain is: xfrmstate -> enacpsk -> netns

Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.

This patch results in a small (~2% in my tests) performance regression.

A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.

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

sched, cpuset: Fix dlcpubusy() panic due to empty cs->cpusallowed

With cgroup v2, the cpuset's cpusallowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpusetcanattach() can call taskcanattach() with an empty mask. This can lead to cpumaskanyand() returns nrcpuids causing the call to dlbwof() to crash due to percpu value access of an out of bound CPU value. For example:

[80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dlcpubusy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpusetcanattach+0xa0/0x140 [80468.209953] cgroupmigrateexecute+0x8c/0x490 [80468.210931] cgroupupdatedflcsses+0x254/0x270 [80468.211898] cgroupsubtreecontrolwrite+0x322/0x400 [80468.212854] kernfsfopwriteiter+0x11c/0x1b0 [80468.213777] newsyncwrite+0x11f/0x1b0 [80468.214689] vfswrite+0x1eb/0x280 [80468.215592] ksyswrite+0x5f/0xe0 [80468.216463] dosyscall64+0x5c/0x80 [80468.224287] entrySYSCALL64afterhwframe+0x44/0xae

Fix that by using effectivecpus instead. For cgroup v1, effectivecpus is the same as cpusallowed. For v2, effectivecpus is the real cpumask to be used by tasks within the cpuset anyway.

Also update taskcanattach()'s 2nd argument name to cseffectivecpus to reflect the change. In addition, a check is added to taskcanattach() to guard against the possibility that cpumaskanyand() may return a value >= nrcpuids.

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

writeback: avoid use-after-free after removing device

When a disk is removed, bdiunregister gets called to stop further writeback and wait for associated delayed work to complete. However, wbinodewritebackend() may schedule bandwidth estimation dwork after this has completed, which can result in the timer attempting to access the just freed bdiwriteback.

Fix this by checking if the bdiwriteback is alive, similar to when scheduling writeback work.

Since this requires wb->worklock, and wbinodewritebackend() may get called from interrupt, switch wb->worklock to an irqsafe lock.

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

pdscore: remove write-after-free of clientid

A use-after-free error popped up in stress testing:

[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdscauxbusdevdel+0xef/0x160 [pdscore] [Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47): [Mon Apr 21 21:21:33 2025] pdscauxbusdevdel+0xef/0x160 [pdscore] [Mon Apr 21 21:21:33 2025] pdscremove+0xc0/0x1b0 [pdscore] [Mon Apr 21 21:21:33 2025] pcideviceremove+0x24/0x70 [Mon Apr 21 21:21:33 2025] devicereleasedriverinternal+0x11f/0x180 [Mon Apr 21 21:21:33 2025] driverdetach+0x45/0x80 [Mon Apr 21 21:21:33 2025] busremovedriver+0x83/0xe0 [Mon Apr 21 21:21:33 2025] pciunregisterdriver+0x1a/0x80

The actual device uninit usually happens on a separate thread scheduled after this code runs, but there is no guarantee of order of thread execution, so this could be a problem. There's no actual need to clear the clientid at this point, so simply remove the offending code.

codel: remove sch->q.qlen check before qdisctreereducebacklog()

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

net: gso: fix panic on fraglist with mixed head alloc types

Since commit 3dcbdb134f32 ("net: gso: Fix skbsegment splat when splitting gsosize mangled skb having linear-headed fraglist"), it is allowed to change gsosize of a GRO packet. However, that commit assumes that "checking the first listskb member suffices; i.e if either of the listskb members have non headfrag head, then the first one has too".

It turns out this assumption does not hold. We've seen BUGON being hit in skbsegment when skbs on the fraglist had differing headfrag with the vmxnet3 driver. This happens because netdevallocskb and napiallocskb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.

There are three different locations where this can be fixed:

(1) We could check headfrag in GRO and not allow GROing skbs with different headfrag. However, that would lead to performance regression on normal forward paths with unmodified gsosize, where !headfrag in the last packet is not a problem.

(2) Set a flag in bpfskbnetgrow and bpfskbnetshrink indicating that NETIFFSG is undesirable. That would need to eat a bit in skbuff. Furthermore, that flag can be unset when all skbs on the fraglist are page backed. To retain good performance, bpfskbnetgrow/shrink would have to walk the fraglist.

(3) Walk the fraglist in skbsegment when determining whether NETIFFSG should be cleared. This of course slows things down.

This patch implements (3). To limit the performance impact in skbsegment, the list is walked only for skbs with SKBGSODODGY set that have gsosize changed. Normal paths thus will not hit it.

We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side.