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

net: rswitch: Avoid use-after-free in rswitchpoll()

The use-after-free is actually in rswitchtxfree(), which is inlined in rswitchpoll(). Since skb and gq->skbs[gq->dirty] are in fact the same pointer, the skb is first freed using devkfreeskbany(), then the value in skb->len is used to update the interface statistics.

Let's move around the instructions to use skb->len before the skb is freed.

This bug is trivial to reproduce using KFENCE. It will trigger a splat every few packets. A simple ARP request or ICMP echo request is enough.

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

smb: client: fix possible double free in smb2setea()

Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~

There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto seaexit' -> 'first memory release for ea' -> 'goto replayagain' -> 'second goto seaexit before allocate memory for ea' -> 'second memory release for ea resulted in double free'.

Re-initialie 'ea' to NULL near to the replayagain label, it can fix this double free problem.

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

bnxten: Fix aggregation ID mask to prevent oops on 5760X chips

The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of the previous generation (5750X or P5). However, the aggregation ID fields in the completion structures on P7 have been redefined from 16 bits to 12 bits. The freed up 4 bits are redefined for part of the metadata such as the VLAN ID. The aggregation ID mask was not modified when adding support for P7 chips. Including the extra 4 bits for the aggregation ID can potentially cause the driver to store or fetch the packet header of GRO/LRO packets in the wrong TPA buffer. It may hit the BUG() condition in skbpull() because the SKB contains no valid packet header:

kernel BUG at include/linux/skbuff.h:2766! Oops: invalid opcode: 0000 1 PREEMPT SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G OE 6.12.0-rc2+ #7 Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022 RIP: 0010:ethtypetrans+0xda/0x140 Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 RSP: 0018:ff615003803fcc28 EFLAGS: 00010283 RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040 RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000 RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001 R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0 R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000 FS: 0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? die+0x33/0x90 ? dotrap+0xd9/0x100 ? ethtypetrans+0xda/0x140 ? doerrortrap+0x65/0x80 ? ethtypetrans+0xda/0x140 ? excinvalidop+0x4e/0x70 ? ethtypetrans+0xda/0x140 ? asmexcinvalidop+0x16/0x20 ? ethtypetrans+0xda/0x140 bnxttpaend+0x10b/0x6b0 [bnxten] ? bnxttpastart+0x195/0x320 [bnxten] bnxtrxpkt+0x902/0xd90 [bnxten] ? bnxttxint.constprop.0+0x89/0x300 [bnxten] ? kmemcachefree+0x343/0x440 ? bnxttxint.constprop.0+0x24f/0x300 [bnxten] bnxtpollwork+0x193/0x370 [bnxten] bnxtpollp5+0x9a/0x300 [bnxten] ? trytowakeup+0x209/0x670 napipoll+0x29/0x1b0

Fix it by redefining the aggregation ID mask for P5PLUS chips to be 12 bits. This will work because the maximum aggregation ID is less than 4096 on all P5PLUS chips.

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

ksmbd: fix potencial out-of-bounds when buffer offset is invalid

I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.

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

wifi: iwlwifi: dbg-tlv: ensure NUL termination

The iwlfwinidebuginfotlv is used as a string, so we must ensure the string is terminated correctly before using it.

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

swiotlb: Fix double-allocation of slots due to broken alignment handling

Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"), which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment checks"), causes a functional regression with vsock in a virtual machine using bouncing via a restricted DMA SWIOTLB pool.

When virtio allocates the virtqueues for the vsock device using dmaalloccoherent(), the SWIOTLB search can return page-unaligned allocations if 'area->index' was left unaligned by a previous allocation from the buffer:

# Final address in brackets is the SWIOTLB address returned to the caller | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800) | virtio-pci 0000:00:07.0: origaddr 0x0 allocsize 0x2000, iotlbalignmask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)

This ends badly (typically buffer corruption and/or a hang) because swiotlballoc() is expecting a page-aligned allocation and so blindly returns a pointer to the 'struct page' corresponding to the allocation, therefore double-allocating the first half (2KiB slot) of the 4KiB page.

Fix the problem by treating the allocation alignment separately to any additional alignment requirements from the device, using the maximum of the two as the stride to search the buffer slots and taking care to ensure a minimum of page-alignment for buffers larger than a page.

This also resolves swiotlb allocation failures occuring due to the inclusion of ~PAGEMASK in 'iotlbalignmask' for large allocations and resulting in alignment requirements exceeding swiotlbmaxmappingsize().

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

HID: wacom: fix crash in wacomaesbatteryhandler()

Commit fd2a9b29dc9c ("HID: wacom: Remove AES powersupply after extended inactivity") introduced wacomaesbatteryhandler() which is scheduled as a delayed work (aesbatterywork).

In wacomremove(), aesbatterywork is not canceled. Consequently, if the device is removed while aesbatterywork is still pending, then hard crashes or "Oops: general protection fault..." are experienced when wacomaesbatteryhandler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aesbatterywork was still pending at the time of hibernation.

So, take care to cancel aesbatterywork in wacomremove().

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

ksmbd: fix slab-out-of-bounds in smbstrndupfromutf16()

If ->NameOffset of smb2createreq is smaller than Buffer offset of smb2createreq, slab-out-of-bounds read can happen from smb2open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2createreq().

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

drm/xe/pf: Clear all LMTT pages on alloc

Our LMEM buffer objects are not cleared by default on alloc and during VF provisioning we only setup LMTT PTEs for the actually provisioned LMEM range. But beyond that valid range we might leave some stale data that could either point to some other VFs allocations or even to the PF pages.

Explicitly clear all new LMTT page to avoid the risk that a malicious VF would try to exploit that gap.

While around add asserts to catch any undesired PTE overwrites and low-level debug traces to track LMTT PT life-cycle.

(cherry picked from commit 3fae6918a3e27cce20ded2551f863fb05d4bef8d)

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

cifs: some missing initializations on replay

In several places in the code, we have a label to signify the start of the code where a request can be replayed if necessary. However, some of these places were missing the necessary reinitializations of certain local variables before replay.

This change makes sure that these variables get initialized after the label.

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

drm/xe: Make dma-fences compliant with the safe access rules

Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a syncfence fd) which will then cause an use- after-free on subsequent access.

To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence.

For the timeline name we simply make the queue be freed via kfreercu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.

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

net/sched: Only allow actct to bind to clsact/ingress qdiscs and shared blocks

As Paolo said earlier [1]:

"Since the blamed commit below, classify can return TCACTCONSUMED while the current skb being held by the defragmentation engine. As reported by GangMin Kim, if such packet is that may cause a UaF when the defrag engine later on tries to tuch again such packet."

actct was never meant to be used in the egress path, however some users are attaching it to egress today [2]. Attempting to reach a middle ground, we noticed that, while most qdiscs are not handling TCACTCONSUMED, clsact/ingress qdiscs are. With that in mind, we address the issue by only allowing actct to bind to clsact/ingress qdiscs and shared blocks. That way it's still possible to attach actct to egress (albeit only with clsact).

[1]

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

ASoC: SOF: Add some bounds checking to firmware data

Smatch complains about "head->fullsize - head->headersize" can underflow. To some extent, we're always going to have to trust the firmware a bit. However, it's easy enough to add a check for negatives, and let's add a upper bounds check as well.

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

ice: fix devlink reload call trace

Commit 4da71a77fc3b ("ice: read internal temperature sensor") introduced internal temperature sensor reading via HWMON. icehwmoninit() was added to iceinitfeature() and icehwmonexit() was added to iceremove(). As a result if devlink reload is used to reinit the device and then the driver is removed, a call trace can occur.

BUG: unable to handle page fault for address: ffffffffc0fd4b5d Call Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 nameshow+0x1f/0x30 devattrshow+0x19/0x60

The call trace repeats approximately every 10 minutes when system monitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs attributes that reference freed module memory.

The sequence is: 1. Driver load, icehwmoninit() gets called from iceinitfeature() 2. Devlink reload down, flow does not call iceremove() 3. Devlink reload up, icehwmoninit() gets called from iceinitfeature() resulting in a second instance 4. Driver unload, icehwmonexit() called from iceremove() leaving the first hwmon instance orphaned with dangling pointer

Fix this by moving icehwmonexit() from iceremove() to icedeinitfeatures() to ensure proper cleanup symmetry with icehwmoninit().

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

RDMA/mana: Remove user triggerable WARNON() in manaibcreateqprss()

Sashiko points out that the user can specify WQs sharing the same CQ as a part of the uAPI and this will trigger the WARNON() then go on to corrupt the kernel.

Just reject it outright and fail the QP creation.

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

block: bio-integrity: Fix null-ptr-deref in biointegritymapuser()

pinuserpagesfast() can partially succeed and return the number of pages that were actually pinned. However, the biointegritymapuser() does not handle this partial pinning. This leads to a general protection fault since bvecfrompages() dereferences an unpinned page address, which is 0.

To fix this, add a check to verify that all requested memory is pinned. If partial pinning occurs, unpin the memory and return -EFAULT.

Kernel Oops:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 0 PID: 1061 Comm: nvme-passthroug Not tainted 7.0.0-11783-g90957f9314e8-dirty #16 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 RIP: 0010:biointegritymapuser.cold+0x1b0/0x9d6

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

net: hns3: fix kernel crash when 1588 is received on HIP08 devices

The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3RXDTSVLDB bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash:

[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclgeptpgetrxhwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclgeptpgetrxhwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclgeptpgetrxhwts+0x40/0x170 [hclge] [ 5889.388304] hns3handlebdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3handlerxbd+0x60/0x150 [hns3] [ 5889.399624] hns3cleanrxring+0x84/0x170 [hns3] [ 5889.405270] hns3niccommonpoll+0xa8/0x220 [hns3] [ 5889.411084] napipoll+0xcc/0x264 [ 5889.415329] netrxaction+0xd4/0x21c [ 5889.419911] dosoftirq+0x130/0x358 [ 5889.424484] irqexit+0x134/0x154 [ 5889.428700] handledomainirq+0x88/0xf0 [ 5889.433684] gichandleirq+0x78/0x2c0 [ 5889.438319] el1irq+0xb8/0x140 [ 5889.442354] archcpuidle+0x18/0x40 [ 5889.446816] defaultidlecall+0x5c/0x1c0 [ 5889.451714] cpuidleidlecall+0x174/0x1b0 [ 5889.456692] doidle+0xc8/0x160 [ 5889.460717] cpustartupentry+0x30/0xfc [ 5889.465523] secondarystartkernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel...

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

nvme: target: rdma: fix ndev refcount leak on queue connect

nvmetrdmaqueueconnect() calls nvmetrdmafindgetdevice() which acquires a reference on the returned ndev via krefget(). On the path where the host queue backlog is exceeded and the function returns NVMESCCONNECTCTRLBUSY, reference of ndev is not released, leaking the kref.

Fix this by adding a goto to the existing putdevice label before the early return.

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

mm, slub: do not call doslabfree for kfence object

In 782f8906f805 the freeing of kfence objects was moved from deep inside doslabfree to the wrapper functions outside. This is a nice change, but unfortunately it missed one spot in kmemcachefreebulk.

This results in a crash like this:

BUG skbuffheadcache (Tainted: G S B E ): Padding overwritten. 0xffff88907fea0f00-0xffff88907fea0fff @offset=3840

slaberr (mm/slub.c:1129) freetopartiallist (mm/slub.c:? mm/slub.c:4036) slabpadcheck (mm/slub.c:864 mm/slub.c:1290) checkslab (mm/slub.c:?) freetopartiallist (mm/slub.c:3171 mm/slub.c:4036) kmemcacheallocbulk (mm/slub.c:? mm/slub.c:4495 mm/slub.c:4586 mm/slub.c:4635) napibuildskb (net/core/skbuff.c:348 net/core/skbuff.c:527 net/core/skbuff.c:549)

All the other callers to doslabfree appear to be ok.

Add a kfencefree check in kmemcachefreebulk to avoid the crash.

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

netdev: prevent accessing NAPI instances from another namespace

The NAPI IDs were not fully exposed to user space prior to the netlink API, so they were never namespaced. The netlink API must ensure that at the very least NAPI instance belongs to the same netns as the owner of the genl sock.

napibyid() can become static now, but it needs to move because of devgetbynapiid().

Integer overflow in raid5cachecount in Linux kernel

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

usb: misc: ljca: Fix double free in error handling path

When auxiliarydeviceadd() returns error and then calls auxiliarydeviceuninit(), callback function ljcaauxdevrelease calls kfree(auxdev->dev.platformdata) to free the parameter data of the function ljcanewclientdevice. The callers of ljcanewclientdevice shouldn't call kfree() again in the error handling path to free the platform data.

Fix this by cleaning up the redundant kfree() in all callers and adding kfree() the passed in platformdata on errors which happen before auxiliarydeviceinit() succeeds .

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

netfilter: nftsetpipapo: release elements in clone only from destroy path

Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice.

This fix requires:

212ed75dc5fb ("netfilter: nftables: integrate pipapo into commit protocol")

which came after:

9827a0e6e23b ("netfilter: nftsetpipapo: release elements in clone from abort path").

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

net/sched: taprio: proper TCATAPRIOTCENTRYINDEX check

taprioparsetcentry() is not correctly checking TCATAPRIOTCENTRYINDEX attribute:

int tc; // Signed value

tc = nlagetu32(tb[TCATAPRIOTCENTRYINDEX]); if (tc >= TCQOPTMAXQUEUE) { NLSETERRMSGMOD(extack, "TC entry index out of range"); return -ERANGE; }

syzbot reported that it could fed arbitary negative values:

UBSAN: shift-out-of-bounds in net/sched/schtaprio.c:1722:18 shift exponent -2147418108 is negative CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2e0 lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:217 [inline] ubsanhandleshiftoutofbounds+0x3c7/0x420 lib/ubsan.c:386 taprioparsetcentry net/sched/schtaprio.c:1722 [inline] taprioparsetcentries net/sched/schtaprio.c:1768 [inline] tapriochange+0xb87/0x57d0 net/sched/schtaprio.c:1877 taprioinit+0x9da/0xc80 net/sched/schtaprio.c:2134 qdisccreate+0x9d4/0x1190 net/sched/schapi.c:1355 tcmodifyqdisc+0xa26/0x1e40 net/sched/schapi.c:1776 rtnetlinkrcvmsg+0x885/0x1040 net/core/rtnetlink.c:6617 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2543 netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x7ea/0x980 net/netlink/afnetlink.c:1367 netlinksendmsg+0xa3b/0xd70 net/netlink/afnetlink.c:1908 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x221/0x270 net/socket.c:745 syssendmsg+0x525/0x7d0 net/socket.c:2584 syssendmsg net/socket.c:2638 [inline] syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7f1b2dea3759 Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 00 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004 RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340 R13: 00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340

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

Bluetooth: btrtl: fix out of bounds memory access

The Linux kernel CVE team has assigned CVE-2024-26890 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041742-CVE-2024-26890-4239@gregkh/T

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

wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces

wilcnetdevcleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver:

echo spi0.1 > /sys/bus/spi/drivers/wilc1000spi/unbind

================================================================== BUG: KASAN: slab-use-after-free in wilcnetdevcleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86

CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x34/0x58 dumpstacklvl from printreport+0x154/0x500 printreport from kasanreport+0xac/0xd8 kasanreport from wilcnetdevcleanup+0x508/0x5cc wilcnetdevcleanup from wilcbusremove+0xc8/0xec wilcbusremove from spiremove+0x8c/0xac spiremove from devicereleasedriverinternal+0x434/0x5f8 devicereleasedriverinternal from unbindstore+0xbc/0x108 unbindstore from kernfsfopwriteiter+0x398/0x584 kernfsfopwriteiter from vfswrite+0x728/0xf88 vfswrite from ksyswrite+0x110/0x1e4 ksyswrite from retfastsyscall+0x0/0x1c

[...]

Allocated by task 1: kasansavetrack+0x30/0x5c kasankmalloc+0x8c/0x94 kmallocnode+0x1cc/0x3e4 kvmallocnode+0x48/0x180 allocnetdevmqs+0x68/0x11dc allocetherdevmqs+0x28/0x34 wilcnetdevifcinit+0x34/0x8ec wilccfg80211init+0x690/0x910 wilcbusprobe+0xe0/0x4a0 spiprobe+0x158/0x1b0 reallyprobe+0x270/0xdf4 driverprobedevice+0x1dc/0x580 driverprobedevice+0x60/0x140 driverattach+0x228/0x5d4 busforeachdev+0x13c/0x1a8 busadddriver+0x2a0/0x608 driverregister+0x24c/0x578 dooneinitcall+0x180/0x310 kernelinitfreeable+0x424/0x484 kernelinit+0x20/0x148 retfromfork+0x14/0x28

Freed by task 86: kasansavetrack+0x30/0x5c kasansavefreeinfo+0x38/0x58 kasanslabfree+0xe4/0x140 kfree+0xb0/0x238 devicerelease+0xc0/0x2a8 kobjectput+0x1d4/0x46c netdevruntodo+0x8fc/0x11d0 wilcnetdevcleanup+0x1e4/0x5cc wilcbusremove+0xc8/0xec spiremove+0x8c/0xac devicereleasedriverinternal+0x434/0x5f8 unbindstore+0xbc/0x108 kernfsfopwriteiter+0x398/0x584 vfswrite+0x728/0xf88 ksyswrite+0x110/0x1e4 retfastsyscall+0x0/0x1c [...]

David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needsfreenetdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list.

Fix this use-after-free thanks to two mechanisms: - navigate in the list with listforeachentrysafe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with listdelrcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregisternetdev)

Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vifmutex lock), we do not need to use RCU list API, that's why we can benefit from listforeachentrysafe.

[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/

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

dm: call the resume method on internal suspend

The Linux kernel CVE team has assigned CVE-2024-26880 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041740-CVE-2024-26880-25d6@gregkh/T

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

rds: tcp: Fix use-after-free of net in reqsktimerhandler().

syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1].

syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows:

18:26:22 executing program 1: r0 = socket$inet6mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)

The notable thing here is 0x4001 in connect(), which is RDSTCPPORT.

So, the scenario would be:

1. unshare(CLONENEWNET) creates a per netns tcp listener in rdstcplisteninit(). 2. syz-executor connect()s to it and creates a reqsk. 3. syz-executor exit()s immediately. 4. netns is dismantled. [0] 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1] 6. listener is freed after RCU grace period. [2]

Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount. However, this was not the case for kernel sockets.

Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inettwskpurge()") fixed this issue only for per-netns ehash.

Let's apply the same fix for the global ehash.

[0]: reftracker: net notrefcnt@0000000065449cc3 has 1/1 users at skalloc (./include/net/netnamespace.h:337 net/core/sock.c:2146) inet6create (net/ipv6/afinet6.c:192 net/ipv6/afinet6.c:119) sockcreate (net/socket.c:1572) rdstcplisteninit (net/rds/tcplisten.c:279) rdstcpinitnet (net/rds/tcp.c:577) opsinit (net/core/netnamespace.c:137) setupnet (net/core/netnamespace.c:340) copynetns (net/core/netnamespace.c:497) createnewnamespaces (kernel/nsproxy.c:110) unsharensproxynamespaces (kernel/nsproxy.c:228 (discriminator 4)) ksysunshare (kernel/fork.c:3429) x64sysunshare (kernel/fork.c:3496) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:129) ... WARNING: CPU: 0 PID: 27 at lib/reftracker.c:179 reftrackerdirexit (lib/reftracker.c:179)

[1]: BUG: KASAN: slab-use-after-free in inetcskreqskqueuedrop (./include/net/inethashtables.h:180 net/ipv4/inetconnectionsock.c:952 net/ipv4/inetconnectionsock.c:966) Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:107 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) kasanreport (mm/kasan/report.c:603) inetcskreqskqueuedrop (./include/net/inethashtables.h:180 net/ipv4/inetconnectionsock.c:952 net/ipv4/inetconnectionsock.c:966) reqsktimerhandler (net/ipv4/inetconnectionsock.c:979 net/ipv4/inetconnectionsock.c:1092) calltimerfn (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) runtimers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) runtimersoftirq (kernel/time/timer.c:2053) dosoftirq (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irqexitrcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) </IRQ>

Allocated by task 258 on cpu 0 at 83.612050s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasanslaballoc (mm/kasan/common.c:343) kmemcachealloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867) copynetns (./include/linux/slab.h:701 net/core/netnamespace.c:421 net/core/netnamespace.c:480) createnewnamespaces (kernel/nsproxy.c:110) unsharensproxyname ---truncated---

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

wifi: mt76: mt7921e: fix use-after-free in freeirq()

From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test to make sure the shared irq handler should be able to handle the unexpected event after deregistration. For this case, let's apply MT76REMOVED flag to indicate the device was removed and do not run into the resource access anymore.

BUG: KASAN: use-after-free in mt7921irqhandler+0xd8/0x100 [mt7921e] Read of size 8 at addr ffff88824a7d3b78 by task rmmod/11115 CPU: 28 PID: 11115 Comm: rmmod Tainted: G W L 5.17.0 #10 Hardware name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I EDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024 Call Trace: dumpstacklvl+0x6f/0xa0 printaddressdescription.constprop.0+0x1f/0x190 ? mt7921irqhandler+0xd8/0x100 [mt7921e] ? mt7921irqhandler+0xd8/0x100 [mt7921e] kasanreport.cold+0x7f/0x11b ? mt7921irqhandler+0xd8/0x100 [mt7921e] mt7921irqhandler+0xd8/0x100 [mt7921e] freeirq+0x627/0xaa0 devmfreeirq+0x94/0xd0 ? devmrequestanycontextirq+0x160/0x160 ? kobjectput+0x18d/0x4a0 mt7921pciremove+0x153/0x190 [mt7921e] pcideviceremove+0xa2/0x1d0 devicereleasedriver+0x346/0x6e0 driverdetach+0x1ef/0x2c0 busremovedriver+0xe7/0x2d0 ? checkobjectsize+0x57/0x310 pciunregisterdriver+0x26/0x250 dosysdeletemodule+0x307/0x510 ? freemodule+0x6a0/0x6a0 ? fpregsassertstateconsistent+0x4b/0xb0 ? rcureadlockschedheld+0x10/0x70 ? syscallenterfromusermode+0x20/0x70 ? tracehardirqson+0x1c/0x130 dosyscall64+0x5c/0x80 ? tracehardirqsonprepare+0x72/0x160 ? dosyscall64+0x68/0x80 ? tracehardirqsonprepare+0x72/0x160 entrySYSCALL64afterhwframe+0x44/0xae

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

tcp: Fix refcnt handling in inethashconnect().

syzbot reported a warning in sknullsdelnodeinitrcu().

The commit 66b60b0c8c4a ("dccp/tcp: Unhash sk from ehash for tb2 alloc failure after checkestalblished().") tried to fix an issue that an unconnected socket occupies an ehash entry when bhash2 allocation fails.

In such a case, we need to revert changes done by checkestablished(), which does not hold refcnt when inserting socket into ehash.

So, to revert the change, we need to sknullsaddnodercu() instead of sknullsaddnodercu().

Otherwise, sockput() will cause refcnt underflow and leak the socket.

[0]: WARNING: CPU: 0 PID: 23948 at include/net/sock.h:799 sknullsdelnodeinitrcu+0x166/0x1a0 include/net/sock.h:799 Modules linked in: CPU: 0 PID: 23948 Comm: syz-executor.2 Not tainted 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:sknullsdelnodeinitrcu+0x166/0x1a0 include/net/sock.h:799 Code: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 <0f> 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2 RSP: 0018:ffffc900032d7848 EFLAGS: 00010246 RAX: ffffffff89cd0035 RBX: 0000000000000001 RCX: 0000000000040000 RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28 R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140 R13: dffffc0000000000 R14: ffff88802a9bf5c0 R15: ffff888021cd6130 FS: 00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> inethashconnect+0x140f/0x20b0 net/ipv4/inethashtables.c:1139 dccpv6connect+0xcb9/0x1480 net/dccp/ipv6.c:956 inetstreamconnect+0x262/0xf30 net/ipv4/afinet.c:678 inetstreamconnect+0x65/0xa0 net/ipv4/afinet.c:749 sysconnectfile net/socket.c:2048 [inline] sysconnect+0x2df/0x310 net/socket.c:2065 dosysconnect net/socket.c:2075 [inline] sesysconnect net/socket.c:2072 [inline] x64sysconnect+0x7a/0x90 net/socket.c:2072 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7f3b8167dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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:00007f3b823f10c8 EFLAGS: 00000246 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX: 00007f3b8167dda9 RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 000000000000000b R14: 00007f3b817abf80 R15: 00007ffd3beb57b8 </TASK>