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

net: usb: aqc111: Fix out-of-bounds accesses in RX fixup

aqc111rxfixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular:

- The metadata array (descoffset..descoffset+2pktcount) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data.

Found doing variant analysis. Tested it with another driver (ax88179178a), since I don't have a aqc111 device to test it, but the code looks very similar.

An out-of-bounds memory write flaw in the Linux kernel’s USB Monitor component was found in how a user with access to the /dev/usbmon can trigger it by an incorrect write to the memory of the usbmon. This flaw allows a local user to crash or potentially escalate their privileges on the system.

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

rpmsg: virtio: Free driveroverride when rpmsgremove()

Free driveroverride when rpmsgremove(), otherwise the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsgns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] kmemcacheallocnode+0x1f8/0x320 [<000000002300d89b>] kmallocnodetrackcaller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driversetoverride+0xd0/0x164 [<000000003e9c4ea5>] rpmsgregisterdeviceoverride+0x98/0x170 [<000000001c0c89a8>] rpmsgnsregisterdevice+0x24/0x30 [<000000008bbf8fa2>] rpmsgprobe+0x2e0/0x3ec [<00000000e65a68df>] virtiodevprobe+0x1c0/0x280 [<00000000443331cc>] reallyprobe+0xbc/0x2dc [<00000000391064b1>] driverprobedevice+0x78/0xe0 [<00000000a41c9a5b>] driverprobedevice+0xd8/0x160 [<000000009c3bd5df>] deviceattachdriver+0xb8/0x140 [<0000000043cd7614>] busforeachdrv+0x7c/0xd4 [<000000003b929a36>] deviceattach+0x9c/0x19c [<00000000a94e0ba8>] deviceinitialprobe+0x14/0x20 [<000000003c999637>] busprobedevice+0xa0/0xac

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

drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga

For pptable structs that use flexible array sizes, use flexible arrays.

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

bpf: Detect IP == ksym.end as part of BPF program

Now that bpfthrow kfunc is the first such call instruction that has noreturn semantics within the verifier, this also kicks in dead code elimination in unprecedented ways. For one, any instruction following a bpfthrow call will never be marked as seen. Moreover, if a callchain ends up throwing, any instructions after the call instruction to the eventually throwing subprog in callers will also never be marked as seen.

The tempting way to fix this would be to emit extra 'int3' instructions which bump the jitedlen of a program, and ensure that during runtime when a program throws, we can discover its boundaries even if the call instruction to bpfthrow (or to subprogs that always throw) is emitted as the final instruction in the program.

An example of such a program would be this:

dosomething(): ... r0 = 0 exit

foo(): r1 = 0 call bpfthrow r0 = 0 exit

bar(cond): if r1 != 0 goto pc+2 call dosomething exit call foo r0 = 0 // Never seen by verifier exit //

main(ctx): r1 = ... call bar r0 = 0 exit

Here, if we do end up throwing, the stacktrace would be the following:

bpfthrow foo bar main

In bar, the final instruction emitted will be the call to foo, as such, the return address will be the subsequent instruction (which the JIT emits as int3 on x86). This will end up lying outside the jitedlen of the program, thus, when unwinding, we will fail to discover the return address as belonging to any program and end up in a panic due to the unreliable stack unwinding of BPF programs that we never expect.

To remedy this case, make bpfprogksymfind treat IP == ksym.end as part of the BPF program, so that isbpftextaddress returns true when such a case occurs, and we are able to unwind reliably when the final instruction ends up being a call instruction.

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

net: mctp: ensure our nlmsg responses are initialised

Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTMGETNEIGH will return uninitalised data in the pad bytes of the ndmsg data.

Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.

drm/amdgpu/sdma4: replace BUGON with WARNON in fence emission

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

spi: spi-mt65xx: Fix NULL pointer access in interrupt handler

The TX buffer in spitransfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes.

Add a check to trans->txbuf before using it.

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

wifi: ar5523: enable proper endpoint verification

Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.

Fix the issue by checking for the existence of all proper endpoints with their according types intact.

Sadly, this patch has not been tested on real hardware.

[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usbsubmiturb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523cmdread drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523hostavailable drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usbprobeinterface+0x30f/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbsetconfiguration+0x101d/0x1900 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xbe/0x100 drivers/usb/core/generic.c:238 usbprobedevice+0xd8/0x2c0 drivers/usb/core/driver.c:293 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbnewdevice.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hubportconnect drivers/usb/core/hub.c:5353 [inline] hubportconnectchange drivers/usb/core/hub.c:5497 [inline] portevent drivers/usb/core/hub.c:5653 [inline] hubevent+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 processonework+0x9bf/0x1710 kernel/workqueue.c:2289 workerthread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>

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

nfsd: return -EINVAL when namelen is 0

When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdupuser() to return ZEROSIZEPTR. When we access the name.data that has been assigned the value of ZEROSIZEPTR in nfs4clienttoreclaim(), null pointer dereference is triggered.

[ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4clienttoreclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dumpstack+0x9a/0xd0 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] kasanreport.cold+0x34/0x84 [ T1205] ? nfs4clienttoreclaim+0xe9/0x260 [ T1205] kasanreport+0x3a/0x50 [ T1205] nfs4clienttoreclaim+0xe9/0x260 [ T1205] ? nfsd4releaselockowner+0x410/0x410 [ T1205] cldpipedowncall+0x5ca/0x760 [ T1205] ? nfsd4cldtrackingexit+0x1d0/0x1d0 [ T1205] ? downwritekillablenested+0x170/0x170 [ T1205] ? avcpolicyseqno+0x28/0x40 [ T1205] ? selinuxfilepermission+0x1b4/0x1e0 [ T1205] rpcpipewrite+0x84/0xb0 [ T1205] vfswrite+0x143/0x520 [ T1205] ksyswrite+0xc9/0x170 [ T1205] ? ia32sysread+0x50/0x50 [ T1205] ? ktimegetcoarserealts64+0xfe/0x110 [ T1205] ? ktimegetcoarserealts64+0xa2/0x110 [ T1205] dosyscall64+0x33/0x40 [ T1205] entrySYSCALL64afterhwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIGRAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================

Fix it by checking namelen.

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

IB/core: Fix ibcachesetupone error flow cleanup

When ibcacheupdate return an error, we exit ibcachesetupone instantly with no proper cleanup, even though before this we had already successfully done gidtablesetupone, that results in the kernel WARN below.

Do proper cleanup using gidtablecleanupone before returning the err in order to fix the issue.

WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gidtablereleaseone+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: crepro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gidtablereleaseone+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0x94/0xa0 ? warn+0x9e/0x1c0 ? gidtablereleaseone+0x181/0x1a0 ? reportbug+0x1f9/0x340 ? gidtablereleaseone+0x181/0x1a0 ? handlebug+0xa2/0x110 ? excinvalidop+0x31/0xa0 ? asmexcinvalidop+0x16/0x20 ? warnprintk+0xc7/0x180 ? warnprintk+0xd4/0x180 ? gidtablereleaseone+0x181/0x1a0 ibdevicerelease+0x71/0xe0 ? pfxibdevicerelease+0x10/0x10 devicerelease+0x44/0xd0 kobjectput+0x135/0x3d0 putdevice+0x20/0x30 rxenetadd+0x7d/0xa0 rxenewlink+0xd7/0x190 nldevnewlink+0x1b0/0x2a0 ? pfxnldevnewlink+0x10/0x10 rdmanlrcvmsg+0x1ad/0x2e0 rdmanlrcvskb.constprop.0+0x176/0x210 netlinkunicast+0x2de/0x400 netlinksendmsg+0x306/0x660 socksendmsg+0x110/0x120 syssendmsg+0x30e/0x390 syssendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouintfromuser+0x7c/0xb0 ? getpidtask+0xb0/0xd0 ? procfailnthwrite+0x5b/0x140 ? fgetlight+0x9a/0x200 ? preemptcountadd+0x47/0xa0 syssendmsg+0x61/0xd0 dosyscall64+0x50/0x110 entrySYSCALL64afterhwframe+0x76/0x7e

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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

[ dhansen: elaborate on suboptimal IBPB solution ]

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

ipv4: Fix reference count leak when using error routes with nexthop objects

When a nexthop object is deleted, it is marked as dead and then fibtableflush() is called to flush all the routes that are using the dead nexthop.

The current logic in fibtableflush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flushall=true). Therefore, error routes are not flushed when their nexthop object is deleted:

# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1

As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:

# ip link del dev dummy1 [ 70.516258] unregisternetdevice: waiting for dummy1 to become free. Usage count = 2

Fix by flushing error routes when their nexthop is marked as dead.

IPv6 does not suffer from this problem.

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

wifi: mac80211: fix NULL pointer dereference in meshrxcsaframe()

In meshrxcsaframe(), elems->meshchanswparamsie is dereferenced at lines 1638 and 1642 without a prior NULL check:

ifmsh->chswttl = elems->meshchanswparamsie->meshttl; ... prevalue = le16tocpu(elems->meshchanswparamsie->meshprevalue);

The meshmatcheslocal() check above only validates the Mesh ID, Mesh Configuration, and Supported Rates IEs. It does not verify the presence of the Mesh Channel Switch Parameters IE (element ID 118). When a received CSA action frame omits that IE, ieee80211parseelems() leaves elems->meshchanswparamsie as NULL, and the unconditional dereference causes a kernel NULL pointer dereference.

A remote mesh peer with an established peer link (PLINKESTAB) can trigger this by sending a crafted SPECTRUMMGMT/CHLSWITCH action frame that includes a matching Mesh ID and Mesh Configuration IE but omits the Mesh Channel Switch Parameters IE. No authentication beyond the default open mesh peering is required.

Crash confirmed on kernel 6.17.0-5-generic via mac80211hwsim:

BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ieee80211meshrxqueuedmgmt+0x143/0x2a0 [mac80211] CR2: 0000000000000000

Fix by adding a NULL check for meshchanswparamsie after meshmatcheslocal() returns, consistent with how other optional IEs are guarded throughout the mesh code.

The bug has been present since v3.13 (released 2014-01-19).

icmp: fix NULL pointer dereference in icmptagvalidation()

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

wifi: mac80211: fix NULL deref in meshmatcheslocal()

meshmatcheslocal() unconditionally dereferences ie->meshconfig to compare mesh configuration parameters. When called from meshrxcsaframe(), the parsed action-frame elements may not contain a Mesh Configuration IE, leaving ie->meshconfig NULL and triggering a kernel NULL pointer dereference.

The other two callers are already safe: - ieee80211meshrxbcnpresp() checks !elems->meshconfig before calling meshmatcheslocal() - meshplinkgetevent() is only reached through meshprocessplinkframe(), which checks !elems->meshconfig, too

meshrxcsaframe() is the only caller that passes raw parsed elements to meshmatcheslocal() without guarding meshconfig. An adjacent attacker can exploit this by sending a crafted CSA action frame that includes a valid Mesh ID IE but omits the Mesh Configuration IE, crashing the kernel.

The captured crash log:

Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: eventsunbound cfg80211wiphywork [...] Call Trace: <TASK> ? pfxmeshmatcheslocal (net/mac80211/mesh.c:65) ieee80211meshrxqueuedmgmt (net/mac80211/mesh.c:1686) [...] ieee80211ifacework (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802) [...] cfg80211wiphywork (net/wireless/core.c:426) processonework (net/kernel/workqueue.c:3280) ? assignwork (net/kernel/workqueue.c:1219) workerthread (net/kernel/workqueue.c:3352) ? pfxworkerthread (net/kernel/workqueue.c:3385) kthread (net/kernel/kthread.c:436) [...] retfromforkasm (net/arch/x86/entry/entry64.S:255) </TASK>

This patch adds a NULL check for ie->meshconfig at the top of meshmatcheslocal() to return false early when the Mesh Configuration IE is absent.

apparmor: fix: limit the number of levels of policy namespaces

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

media: pvrusb2: fix uaf in pvr2contextsetnotify

[Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26

CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usbhubwq hubevent Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2contextnotify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2contextdisconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272

Freed by task 906: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] kasanslabfree+0x106/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inline] slabfree mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2contextcheck drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2contextthreadfunc+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158

[Analyze] Task A set disconnectflag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue.

[Fix] Place the disconnectflag assignment operation after all code in pvr2contextdisconnect() to avoid this issue.

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

mlxsw: spectrumacltcam: Fix memory leak during rehash

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35853-869a@gregkh/T

bpf: reject short IPv4/IPv6 inputs in bpfprogtestrunskb

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

wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated.

Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 ieee80211wakequeue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) sndseqdummy sndhrtimer sndseq sndseqdevice nftchainnat xtMASQUERADE nfnat xfrmuser xfrmalgo xtaddrtype overlay ccm afpacket amdgpu sndhdacodeccirrus sndhdacodecgeneric ledtrigaudio drmexec amdxcp gpusched xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 ip6trpfilter iptrpfilter xtpkttype xtLOG nflogsyslog xttcpudp nftcompat nftables nfnetlink schfqcodel btusb uinput iTCOwdt ctr btrtl intelpmcbxt i915 intelraplmsr meihdcp meipxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldifmap btmtk intelraplcommon sndhdacodechdmi bluetooth uvcvideo nlsiso88591 applesmc nlscp437 x86pkgtempthermal sndhdaintel intelpowerclamp vfat videobuf2vmalloc coretemp fat sndinteldspcfg crc32pclmul uvc polyvalclmulni sndintelsdwacpi loop videobuf2memops sndhdacodec tun drmsuballochelper polyvalgeneric drmttmhelper drmbuddy tap ecdhgeneric videobuf2v4l2 gf128mul macvlan ttm ghashclmulniintel ecc tg3 [ +0.000044] videodev bridge sndhdacore rapl crc16 drmdisplayhelper cec mousedev sndhwdep evdev intelcstate bcm5974 hidappleir videobuf2common stp machid libphy sndpcm drmkmshelper acpials meime inteluncore llc mc sndtimer intelgtt industrialiotriggeredbuffer applemfifastcharge i2ci801 mei snd lpcich agpgart ptp i2csmbus thunderbolt applegmux i2calgobit kfifobuf video industrialio soundcore ppscore wmi tinypowerbutton sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvmintel kvm drm irqbypass fuse backlight firmwareclass efipstore configfs efivarfs dmisysfs iptables xtables autofs4 dmcrypt cbc encryptedkeys trusted asn1encoder tee tpm rngcore inputleds hidapple ledclass hidgeneric usbhid hid sdmod t10pi crc64rocksoft crc64 crct10dif crct10difgeneric ahci libahci libata uhcihcd ehcipci ehcihcd crct10difpclmul crct10difcommon sha512ssse3 sha512generic sha256ssse3 sha1ssse3 aesniintel usbcore scsimod libaes cryptosimd cryptd scsicommon [ +0.000055] usbcommon rtccmos btrfs blake2bgeneric libcrc32c crc32cgeneric crc32cintel xor raid6pq dmsnapshot dmbufio dmmod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:ieee80211wakequeue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated---

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

afunix: Clear stale u->oobskb.

syzkaller started to report deadlock of unixgclock after commit 4090fa373f0e ("afunix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("afunix: Add OOB support").

The repro basically does the following.

from socket import from array import array

c1, c2 = socketpair(AFUNIX, SOCKSTREAM) c1.sendmsg([b'a'], [(SOLSOCKET, SCMRIGHTS, array("i", [c2.fileno()]))], MSGOOB) c2.recv(1) # blocked as no normal data in recv queue

c2.close() # done async and unblock recv() c1.close() # done async and trigger GC

A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close().

The problem here is wrong handling of OOB skb in manageoob(). When recvmsg() is called without MSGOOB, manageoob() is called to check if the peeked skb is OOB skb. In such a case, manageoob() pops it out of the receive queue but does not clear unixsock(sk)->oobskb. This is wrong in terms of uAPI.

Let's say we send "hello" with MSGOOB, and "world" without MSGOOB. The 'o' is handled as OOB data. When recv() is called twice without MSGOOB, the OOB data should be lost.

>>> from socket import >>> c1, c2 = socketpair(AFUNIX, SOCKSTREAM, 0) >>> c1.send(b'hello', MSGOOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSGOOB) # This should return an error b'o'

In the same situation, TCP actually returns -EINVAL for the last recv().

Also, if we do not clear unixsk(sk)->oobskb, unixpoll() always set EPOLLPRI even though the data has passed through by previous recv().

To avoid these issues, we must clear unixsk(sk)->oobskb when dequeuing it from recv queue.

The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop.

When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket.

With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.

bpf: Avoid uninitialized value in BPFCOREREADBITFIELD

drbd: fix "LOGIC BUG" in drbdalbeginiononblock()

A use-after-free flaw was found in xgenehwmonremove in drivers/hwmon/xgene-hwmon.c in the Hardware Monitoring Linux Kernel Driver (xgene-hwmon). This flaw could allow a local attacker to crash the system due to a race problem. This vulnerability could even lead to a kernel information leak problem.

fsdax: Fix infinite loop in daxiomaprw()

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

media: vidtv: psi: Add check for kstrdup

Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.

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

clk: mediatek: clk-mt7629: Add check for mtkallocclkdata

Add the check for the return value of mtkallocclkdata() in order to avoid NULL pointer dereference.

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

ipv6: sr: fix missing skbuff release in seg6inputcore

The seg6input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6inputcore(). This function uses the skbcowhead() to ensure that there is sufficient headroom in the skbuff for accommodating the link-layer header. In the event that the skbcowheader() function fails, the seg6inputcore() catches the error but it does not release the skbuff, which will result in a memory leak.

This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6input() code was refactored to deal with netfilter hooks.

The proposed patch addresses the identified memory leak by requiring the seg6inputcore() function to release the skbuff in the event that skbcowhead() fails.

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

netfilter: nftpayload: sanitize offset and length before calling skbchecksum()

If access to offset + length is larger than the skbuff length, then skbchecksum() triggers BUGON().

skbchecksum() internally subtracts the length parameter while iterating over skbuff, BUGON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.