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:

KVM: x86: Immediately reset the MMU context when the SMM flag is cleared

Immediately reset the MMU context when the vCPU's SMM flag is cleared so that the SMM flag in the MMU role is always synchronized with the vCPU's flag. If RSM fails (which isn't correctly emulated), KVM will bail without calling postleavesmm() and leave the MMU in a bad state.

The bad MMU role can lead to a NULL pointer dereference when grabbing a shadow page's rmap for a page fault as the initial lookups for the gfn will happen with the vCPU's SMM flag (=0), whereas the rmap lookup will use the shadow page's SMM flag, which comes from the MMU (=1). SMM has an entirely different set of memslots, and so the initial lookup can find a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:gfntormap arch/x86/kvm/mmu/mmu.c:935 [inline] RIP: 0010:gfntormap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947 Code: <42> 80 3c 20 00 74 08 4c 89 ff e8 f1 79 a9 00 4c 89 fb 4d 8b 37 44 RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002 R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000 R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000 FS: 000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rmapadd arch/x86/kvm/mmu/mmu.c:965 [inline] mmusetspte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604 directmap arch/x86/kvm/mmu/mmu.c:2862 [inline] directpagefault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769 kvmmmudopagefault arch/x86/kvm/mmu.h:124 [inline] kvmmmupagefault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065 vmxhandleexit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122 vcpuenterguest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428 vcpurun+0x416/0xc20 arch/x86/kvm/x86.c:9494 kvmarchvcpuioctlrun+0x4e8/0xa40 arch/x86/kvm/x86.c:9722 kvmvcpuioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvmmain.c:3460 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:1069 [inline] sesysioctl+0xfb/0x170 fs/ioctl.c:1055 dosyscall64+0x3f/0xb0 arch/x86/entry/common.c:47 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x440ce9

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.

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:

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:

usb: fix various gadget panics on 10gbps cabling

usbassigndescriptors() is called with 5 parameters, the last 4 of which are the usbdescriptorheader for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps).

The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough).

However if a gadget driver calls usbassigndescriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it)

The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided.

Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way).

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.

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

ptp: ocp: Fix a resource leak in an error handling path

If an error occurs after a successful 'pciioremapbar()' call, it must be undone by a corresponding 'pciiounmap()' call, as already done in the remove function.

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

x86/ioremap: Map EFI-reserved memory as encrypted for SEV

Some drivers require memory that is marked as EFI boot services data. In order for this memory to not be re-used by the kernel after ExitBootServices(), efimemreserve() is used to preserve it by inserting a new EFI memory descriptor and marking it with the EFIMEMORYRUNTIME attribute.

Under SEV, memory marked with the EFIMEMORYRUNTIME attribute needs to be mapped encrypted by Linux, otherwise the kernel might crash at boot like below:

EFI Variables Facility v0.08 2004-May-17 general protection fault, probably for non-canonical address 0x3597688770a868b2: 0000 [#1] SMP NOPTI CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:efimokvarentrynext [...] Call Trace: efimokvarsysfsinit ? efimokvartableinit dooneinitcall ? kmalloc kernelinitfreeable ? restinit kernelinit retfromfork

Expand the ioremapcheckother() function to additionally check for this other type of boot data reserved at runtime and indicate that it should be mapped encrypted for an SEV guest.

[ bp: Massage commit message. ]

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

scsi: megaraidsas: Fix resource leak in case of probe failure

The driver doesn't clean up all the allocated resources properly when scsiaddhost(), megasasstartaen() function fails during the PCI device probe.

Clean up all those resources.

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

blktrace: Fix uaf in blktrace access after removing by sysfs

There is an use-after-free problem triggered by following process:

P1(sda) P2(sdb) echo 0 > /sys/block/sdb/trace/enable blktraceremovequeue synchronizercu blktracefree relayclose rcureadlock blkaddtrace tracenotetsk (Iterate runningtracelist) relayclosebuf relaydestroybuf kfree(buf) tracenote(sdb's bt) relayreserve buf->offset <- nullptr deference (use-after-free) !!! rcureadunlock

[ 502.714379] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 502.715260] #PF: supervisor read access in kernel mode [ 502.715903] #PF: errorcode(0x0000) - not-present page [ 502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0 [ 502.717252] Oops: 0000 [#1] SMP [ 502.720308] RIP: 0010:tracenote.isra.0+0x86/0x360 [ 502.732872] Call Trace: [ 502.733193] blkaddtrace.cold+0x137/0x1a3 [ 502.733734] blkaddtracerq+0x7b/0xd0 [ 502.734207] blkaddtracerqissue+0x54/0xa0 [ 502.734755] blkmqstartrequest+0xde/0x1b0 [ 502.735287] scsiqueuerq+0x528/0x1140 ... [ 502.742704] sgnewwrite.isra.0+0x16e/0x3e0 [ 502.747501] sgioctl+0x466/0x1100

Reproduce method: ioctl(/dev/sda, BLKTRACESETUP, blkusertracesetup[bufsize=127]) ioctl(/dev/sda, BLKTRACESTART) ioctl(/dev/sdb, BLKTRACESETUP, blkusertracesetup[bufsize=127]) ioctl(/dev/sdb, BLKTRACESTART)

echo 0 > /sys/block/sdb/trace/enable & // Add delay(mdelay/msleep) before kernel enters blktracefree()

ioctl$SGIO(/dev/sda, SGIO, ...) // Enters tracenotetsk() after blktracefree() returned // Use mdelay in rcu region rather than msleep(which may schedule out)

Remove blktrace from runninglist before calling blktracefree() by sysfs if blktrace is at Blktracerunning state.

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.