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

ksmbd: fix use-after-free in SMB request handling

A race condition exists between SMB request handling in ksmbdconnhandlerloop() and the freeing of ksmbdconn in the workqueue handler handleksmbdwork(). This leads to a UAF. - KASAN: slab-use-after-free Read in handleksmbdwork - KASAN: slab-use-after-free in rtlockslowlocklocked

This race condition arises as follows: - ksmbdconnhandlerloop() waits for conn->rcount to reach zero: waitevent(conn->rcountq, atomicread(&conn->rcount) == 0); - Meanwhile, handleksmbdwork() decrements conn->rcount using atomicdecreturn(&conn->rcount), and if it reaches zero, calls ksmbdconnfree(), which frees conn. - However, after handleksmbdwork() decrements conn->rcount, it may still access conn->rcountq in the following line: waitqueueactive(&conn->rcountq) or wakeup(&conn->rcountq) This results in a UAF, as conn has already been freed.

The discovery of this UAF can be referenced in the following PR for syzkaller's support for SMB requests.

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

smb: During unmount, ensure all cached dir instances drop their dentry

The unmount process (cifskillsb() calling closeallcacheddirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:

BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!

This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:

- Receiving a lease break from the server - Server reconnection triggers invalidateallcacheddirs(), which removes all the cfids from the list - The laundromat thread decides to expire an old cfid.

To solve these problems, dropping the dentry is done in queued work done in a newly-added cfidputwq workqueue, and closeallcacheddirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.

The final cleanup work for cleaning up a cfid is performed via work queued in the serverclosewq workqueue; this is done separate from dropping the dentries so that closeallcacheddirs() doesn't block on any server operations.

Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.

While we're here, add proper locking to closeallcacheddirs(), and locking around the freeing of cfid->dentry.

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

nvme-fabrics: fix kernel crash while shutting down controller

The nvme keep-alive operation, which executes at a periodic interval, could potentially sneak in while shutting down a fabric controller. This may lead to a race between the fabric controller admin queue destroy code path (invoked while shutting down controller) and hw/hctx queue dispatcher called from the nvme keep-alive async request queuing operation. This race could lead to the kernel crash shown below:

Call Trace: autoremovewakefunction+0x0/0xbc (unreliable) blkmqscheddispatchrequests+0x114/0x24c blkmqscheddispatchrequests+0x44/0x84 blkmqrunhwqueue+0x140/0x220 nvmekeepalivework+0xc8/0x19c [nvmecore] processonework+0x200/0x4e0 workerthread+0x340/0x504 kthread+0x138/0x140 startkernelthread+0x14/0x18

While shutting down fabric controller, if nvme keep-alive request sneaks in then it would be flushed off. The nvmekeepaliveendio function is then invoked to handle the end of the keep-alive operation which decrements the admin->qusagecounter and assuming this is the last/only request in the admin queue then the admin->qusagecounter becomes zero. If that happens then blk-mq destroy queue operation (blkmqdestroy queue()) which could be potentially running simultaneously on another cpu (as this is the controller shutdown code path) would forward progress and deletes the admin queue. So, now from this point onward we are not supposed to access the admin queue resources. However the issue here's that the nvme keep-alive thread running hw/hctx queue dispatch operation hasn't yet finished its work and so it could still potentially access the admin queue resource while the admin queue had been already deleted and that causes the above crash.

The above kernel crash is regression caused due to changes implemented in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"). Ideally we should stop keep-alive before destroyin g the admin queue and freeing the admin tagset so that it wouldn't sneak in during the shutdown operation. However we removed the keep alive stop operation from the beginning of the controller shutdown code path in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()") and added it under nvmeuninitctrl() which executes very late in the shutdown code path after the admin queue is destroyed and its tagset is removed. So this change created the possibility of keep-alive sneaking in and interfering with the shutdown operation and causing observed kernel crash.

To fix the observed crash, we decided to move nvmestopkeepalive() from nvmeuninitctrl() to nvmeremoveadmintagset(). This change would ensure that we don't forward progress and delete the admin queue until the keep- alive operation is finished (if it's in-flight) or cancelled and that would help contain the race condition explained above and hence avoid the crash.

Moving nvmestopkeepalive() to nvmeremoveadmintagset() instead of adding nvmestopkeepalive() to the beginning of the controller shutdown code path in nvmestopctrl(), as was the case earlier before commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"), would help save one callsite of nvmestopkeepalive().

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

bnxten: Fix receive ring space parameters when XDP is active

The MTU setting at the time an XDP multi-buffer is attached determines whether the aggregation ring will be used and the rxskbfunc handler. This is done in bnxtsetrxskbmode().

If the MTU is later changed, the aggregation ring setting may need to be changed and it may become out-of-sync with the settings initially done in bnxtsetrxskbmode(). This may result in random memory corruption and crashes as the HW may DMA data larger than the allocated buffer size, such as:

BUG: kernel NULL pointer dereference, address: 00000000000003c0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1 Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E3A12 08/26/2021 RIP: 0010:bnxtrxpkt+0xe97/0x1ae0 [bnxten] Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202 RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff RDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380 RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf R10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980 R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990 FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> bnxtpollwork+0x1c2/0x3e0 [bnxten]

To address the issue, we now call bnxtsetrxskbmode() within bnxtchangemtu() to properly set the AGG rings configuration and update rxskbfunc based on the new MTU value. Additionally, BNXTFLAGNOAGGRINGS is cleared at the beginning of bnxtsetrxskbmode() to make sure it gets set or cleared based on the current MTU.

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

RDMA/bnxtre: Fix max SGEs for the Work Request

Gen P7 supports up to 13 SGEs for now. WQE software structure can hold only 6 now. Since the max send sge is reported as 13, the stack can give requests up to 13 SGEs. This is causing traffic failures and system crashes.

Use the define for max SGE supported for variable size. This will work for both static and variable WQEs.

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

RDMA/rtrs: Add missing deinit() call

A warning is triggered when repeatedly connecting and disconnecting the rnbd: listadd corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340). WARNING: CPU: 1 PID: 36562 at lib/listdebug.c:32 listaddvalidorreport+0x7f/0xa0 Workqueue: ibcm cmworkhandler [ibcm] RIP: 0010:listaddvalidorreport+0x7f/0xa0 ? listaddvalidorreport+0x7f/0xa0 ibregistereventhandler+0x65/0x93 [ibcore] rtrssrvibdevinit+0x29/0x30 [rtrsserver] rtrsibdevfindoradd+0x124/0x1d0 [rtrscore] allocpath+0x46c/0x680 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] ? rcuiswatching+0xd/0x40 ? mutexlock+0x312/0xcf0 ? getorcreatesrv+0xad/0x310 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] rtrsrdmaconnect+0x23c/0x2d0 [rtrsserver] ? lockrelease+0x1b1/0x2d0 cmacmeventhandler+0x4a/0x1a0 [rdmacm] cmaibreqhandler+0x3a0/0x7e0 [rdmacm] cmprocesswork+0x28/0x1a0 [ibcm] ? rawspinunlockirq+0x2f/0x50 cmreqhandler+0x618/0xa60 [ibcm] cmworkhandler+0x71/0x520 [ibcm]

Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a new element .deinit but never used it at all. Fix it by invoking the deinit() to appropriately unregister the IB event handler.

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

netmem: prevent TX of unreadable skbs

Currently on stable trees we have support for netmem/devmem RX but not TX. It is not safe to forward/redirect an RX unreadable netmem packet into the device's TX path, as the device may call dma-mapping APIs on dma addrs that should not be passed to it.

Fix this by preventing the xmit of unreadable skbs.

Tested by configuring tc redirect:

sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ipproto \ tcp srcip 192.168.1.12 action mirred egress redirect dev eth1

Before, I see unreadable skbs in the driver's TX path passed to dma mapping APIs.

After, I don't see unreadable skbs in the driver's TX path passed to dma mapping APIs.

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

netfs: Fix oops in write-retry from mis-resetting the subreq iterator

Fix the resetting of the subrequest iterator in netfsretrywritestream() to use the iterator-reset function as the iterator may have been shortened by a previous retry. In such a case, the amount of data to be written by the subrequest is not "subreq->len" but "subreq->len - subreq->transferred".

Without this, KASAN may see an error in ioviterrevert():

BUG: KASAN: slab-out-of-bounds in ioviterrevert lib/ioviter.c:633 [inline] BUG: KASAN: slab-out-of-bounds in ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147

CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: eventsunbound netfswritecollectionworker Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 ioviterrevert lib/ioviter.c:633 [inline] ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 netfsretrywritestream fs/netfs/writeretry.c:44 [inline] netfsretrywrites+0x166d/0x1a50 fs/netfs/writeretry.c:231 netfscollectwriteresults fs/netfs/writecollect.c:352 [inline] netfswritecollectionworker+0x23fd/0x3830 fs/netfs/writecollect.c:374 processonework+0x9cf/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

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

cifs: Fix oops due to uninitialised variable

Fix smb3inittransformrq() to initialise buffer to NULL before calling netfsallocfolioqbuffer() as netfs assumes it can append to the buffer it is given. Setting it to NULL means it should start a fresh buffer, but the value is currently undefined.

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

netfs: Fix netfsreadtopagecache() to pause on subreq failure

Fix netfsreadtopagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails.

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

svcrdma: bound check rqpages index in inline path

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rccurpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.

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

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

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

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

RDMA/mlx5: Move events notifier registration to be after device registration

Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events.

Fix a race between the device deregistration and pkey change work by moving MLX5IBSTAGEDEVICENOTIFIER to be after MLX5IBSTAGEIBREG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below.

BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el91.x8664 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkeychangehandler [mlx5ib] RIP: 0010:setupqp+0x38/0x1f0 [mlx5ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5ibgsipkeychange+0x20/0x40 [mlx5ib] processonework+0x1e8/0x3c0 workerthread+0x50/0x3b0 ? rescuerthread+0x380/0x380 kthread+0x149/0x170 ? setkthreadstruct+0x50/0x50 retfromfork+0x22/0x30 Modules linked in: rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) mlx5fwctl(OE) fwctl(OE) ibuverbs(OE) mlx5core(OE) mlxdevm(OE) ibcore(OE) mlxcompat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfsacl nfs lockd grace fscache netfs qrtr rfkill sunrpc intelraplmsr intelraplcommon rapl hvballoon hvutils i2cpiix4 pcspkr joydev fuse ext4 mbcache jbd2 srmod sdmod cdrom t10pi sg atageneric pcihyperv pcihypervintf hypervdrm drmshmemhelper drmkmshelper hvstorvsc syscopyarea hvnetvsc sysfillrect sysimgblt hidhyperv fbsysfops scsitransportfc hypervkeyboard drm atapiix crct10difpclmul crc32pclmul crc32cintel libata ghashclmulniintel hvvmbus serioraw [last unloaded: ibcore] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---

Bluetooth: fix use-after-free in deviceforeachchild()

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

iommu/vt-d: Restore context entry setup order for aliased devices

Commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain") changed the context entry setup during domain attachment from a set-and-check policy to a clear-and-reset approach. This inadvertently introduced a regression affecting PCI aliased devices behind PCIe-to-PCI bridges.

Specifically, keyboard and touchpad stopped working on several Apple Macbooks with below messages:

kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spimaster/spi2/spi-APP000D:00/input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NOPASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NOPASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NOPASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00

Fix this by restoring the previous context setup order.

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

wifi: mt76: fix linked list corruption

Never leave scheduled wcid entries on the temporary on-stack list

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

ksmbd: fix null pointer dereference in allocpreauthhash()

The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauthinfo is not allocated. This patch add KSMBDSESSNEEDSETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.

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

ice: fix using untrusted value of pktlen in icevcfdirparseraw()

Fix using the untrusted value of proto->raw.pktlen in function icevcfdirparseraw() by verifying if it does not exceed the VIRTCHNLMAXSIZERAWPACKET value.

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

ALSA: timer: Forcibly close timer instances at closing

When sndtimer object is freed via sndtimerfree() and still pending sndtimerinstance objects are assigned to the timer object, it tries to unlink all instances and just set NULL to each ti->timer, then releases the resources immediately. The problem is, however, when there are slave timer instances that are associated with a master instance linked to this timer: namely, those slave instances still point to the freed timer object although the master instance is unlinked, which may lead to user-after-free. The bug can be easily triggered particularly when a new userspace-driven timers (CONFIGSNDUTIMER) is involved, since it can create and delete the timer object via a simple file open/close, while the other applications may keep accessing to that timer.

This patch is an attempt to paper over the problem above: now instead of just unlinking, call sndtimercloselocked forcibly for each pending timer instance, so that all assigned slave timer instances are properly detached, too. Since sndtimerclose() might be called later by the driver that created that instance, the check of SNDRVTIMERIFLGDEAD is added at the beginning, too.

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

mailbox: mtk-cmdq: fix wrong use of sizeof in cmdqgetclocks()

It should be size of the struct clkbulkdata, not data pointer pass to devmkcalloc().

9p/xen: fix release of IRQ

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

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

The variable 'parent' is assigned the value of 'nchangeset' earlier in the function, meaning both point to the same struct devicenode. The call to ofnodeput(nchangeset) can decrement the reference count to zero and free the node if there are no other holders. After that, the code still uses 'parent' to check for the presence of a property and to read a string property, leading to a use-after-free.

Fix this by moving the ofnodeput() call after the last access to 'parent', avoiding the UAF.

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

bpf: Validate BTF repeated field counts before expansion

btfparsestructmetas() walks user-supplied BTF during BPFBTFLOAD, and btfrepeatfields() expands repeatable fields from array elements into the fixed BTFFIELDSMAX scratch array used by btfparsefields().

The remaining-capacity check performs the expanded field count calculation in u32. A malformed BTF can wrap that calculation, causing the check to pass even when the expanded field count exceeds the scratch array capacity. The following memcpy() can then write past the end of the array.

Use checked addition and multiplication before copying repeated fields and reject impossible counts.

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

svcrdma: Address an integer overflow

Dan Carpenter reports: Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data structure") from Jun 22, 2020 (linux-next), leads to the following Smatch static checker warning: net/sunrpc/xprtrdma/svcrdmarecvfrom.c:498 xdrcheckwritechunk() warn: potential user controlled sizeof overflow 'segcount 4 4' net/sunrpc/xprtrdma/svcrdmarecvfrom.c 488 static bool xdrcheckwritechunk(struct svcrdmarecvctxt rctxt) 489 { 490 u32 segcount; 491 be32 p; 492 493 if (xdrstreamdecodeu32(&rctxt->rcstream, &segcount)) ^^^^^^^^ 494 return false; 495 496 / A bogus segcount causes this buffer overflow check to fail. / 497 p = xdrinlinedecode(&rctxt->rcstream, --> 498 segcount rpcrdmasegmentmaxsz sizeof(p)); segcount is an untrusted u32. On 32bit systems anything >= SIZEMAX / 16 will have an integer overflow and some those values will be accepted by xdrinlinedecode().

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:

netfilter: handle unreadable frags

sashiko reports: When an skb with unreadable fragments (such as from devmem TCP, where skbfragsreadable(skb) returns false) is processed by the u32 module, skbcopybits() will safely return a negative error code [..]

xtu32: bail out with hotdrop in this case. gatherfrags: return -1, just as if we had no fragment header. nfnetlinkqueue: restrict to the linear part. nfnetlinklog: restrict to the linear part.

v2: - skbzerocopy helpers don't copy readable flag, i.e. nfnetlinkqueue is broken too xtu32 shouldn't return true if hotdrop was set.

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

greybus: gb-beagleplay: bound bootloader receive buffering

cc1352bootloaderrx() appends each serdev chunk into the fixed rxbuffer before parsing bootloader packets. The helper can keep leftover bytes between callbacks and may receive multiple packets in one callback, so a single count value is not constrained by one packet length.

Check that the incoming chunk fits in the remaining receive buffer space before memcpy(). If it does not, drop the staged data and consume the bytes instead of overflowing rxbuffer.

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

media: uvcvideo: Skip parsing frames of type UVCVSUNDEFINED in uvcparseformat

This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvcparsestreaming.

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

hvsock: Initializing vsk->trans to NULL to prevent a dangling pointer

When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.