The Linux Kernel, the operating system core itself.

Security Fix(es):

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

s390/qeth: fix deadlock during failing recovery

Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed taking disciplinemutex inside qethdoreset(), fixing potential deadlocks. An error path was missed though, that still takes disciplinemutex and thus has the original deadlock potential.

Intermittent deadlocks were seen when a qeth channel path is configured offline, causing a race between qethdoreset and ccwgroupremove. Call qethsetoffline() directly in the qethdoreset() error case and then a new variant of ccwgroupsetoffline(), without taking disciplinemutex.(CVE-2021-47382)

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

NFSD: Fix the behavior of READ near OFFSET_MAX

Dan Aloni reports: > Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to > the RPC read layers") on the client, a read of 0xfff is aligned up > to server rsize of 0x1000. > > As a result, in a test where the server has a file of size > 0x7fffffffffffffff, and the client tries to read from the offset > 0x7ffffffffffff000, the read causes loff_t overflow in the server > and it returns an NFS code of EINVAL to the client. The client as > a result indefinitely retries the request.

The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ.

Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers.

Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to lofft internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb->smaxbytes do not work properly.(CVE-2022-48827)

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

net: can: j1939: enhanced error handling for tightly received RTS messages in xtprxrtssessionnew

This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARNONONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939xtprx_rts().

Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done(CVE-2023-52887)

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

ipvlan: Dont Use skb->sk in ipvlanprocessv{4,6}_outbound

Raw packet from PFPACKET socket ontop of an IPv6-backed ipvlan device will hit WARNONONCE() in skmcloop() through schdirect_xmit() path.

WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 skmcloop+0x2d/0x70 Modules linked in: schnetem ipvlan rfkill cirrus drmshmemhelper sg drmkmshelper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skmcloop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? _warn (kernel/panic.c:693) ? skmcloop (net/core/sock.c:760) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:239) ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? skmcloop (net/core/sock.c:760) ip6finishoutput2 (net/ipv6/ip6output.c:83 (discriminator 1)) ? nfhookslow (net/netfilter/core.c:626) ip6finishoutput (net/ipv6/ip6output.c:222) ? _pfxip6finishoutput (net/ipv6/ip6output.c:215) ipvlanxmitmodel3 (drivers/net/ipvlan/ipvlancore.c:602) ipvlan ipvlanstartxmit (drivers/net/ipvlan/ipvlanmain.c:226) ipvlan devhardstartxmit (net/core/dev.c:3594) schdirectxmit (net/sched/schgeneric.c:343) _qdiscrun (net/sched/schgeneric.c:416) nettxaction (net/core/dev.c:5286) handlesoftirqs (kernel/softirq.c:555) _irqexitrcu (kernel/softirq.c:589) sysvecapictimer_interrupt (arch/x86/kernel/apic/apic.c:1043)

The warning triggers as this: packetsendmsg packetsnd //skb->sk is packet sk _devqueuexmit _devxmitskb //q->enqueue is not NULL _qdiscrun schdirectxmit devhardstartxmit ipvlanstartxmit ipvlanxmitmodel3 //l3 mode ipvlanprocessoutbound //vepa flag ipvlanprocessv6outbound ip6localout _ip6finishoutput ip6finishoutput2 //multicast packet skmcloop //sk->skfamily is AFPACKET

Call ip{6}localout() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)

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

usb: gadget: ncm: Fix handling of zero block length packets

While connecting to a Linux host with CDCNCMNTBDEFSIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present.

According to the NCM spec:

"If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent.

wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues.

wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB"

However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.(CVE-2024-35825)

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

drm: vc4: Fix possible null pointer dereference

In vc4hdmiaudioinit() ofget_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38546)

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

kunit: Fix kthread reference

There is a race condition when a kthread finishes after the deadline and before the call to kthread_stop(), which may lead to use after free.(CVE-2024-38561)

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

net: stmmac: move the EST lock to struct stmmac_priv

Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization.

DEBUGLOCKSWARNON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 _mutexlock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _mutexlock+0xd84/0x1068 lr : _mutexlock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: _mutexlock+0xd84/0x1068 mutexlocknested+0x28/0x34 tcsetuptaprio+0x118/0x68c stmmacsetuptc+0x50/0xf0 tapriochange+0x868/0xc9c(CVE-2024-38594)

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

stm class: Fix a double free in stmregisterdevice()

The putdevice(&stm->dev) call will trigger stmdevice_release() which frees "stm" so the vfree(stm) on the next line is a double free.(CVE-2024-38627)

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

drm/shmem-helper: Fix BUGON() on mmap(PROTWRITE, MAP_PRIVATE)

Lack of check for copy-on-write (COW) mapping in drmgemshmemmmap allows users to call mmap with PROTWRITE and MAPPRIVATE flag causing a kernel panic due to BUGON in vmfinsertpfnprot: BUGON((vma->vmflags & VMPFNMAP) && iscowmapping(vma->vm_flags));

Return -EINVAL early if COW mapping is detected.

This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROTWRITE, MAPPRIVATE, fd, mmap_offset); ptr[0] = 0;(CVE-2024-39497)

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

net: hns3: fix kernel crash problem in concurrent scenario

When link status change, the nic driver need to notify the roce driver to handle this event, but at this time, the roce driver may uninit, then cause kernel crash.

To fix the problem, when link status change, need to check whether the roce registered, and when uninit, need to wait link update finish.(CVE-2024-39507)

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

ax25: Fix refcount imbalance on inbound connections

When releasing a socket in ax25release(), we call netdevput() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes.

A typical call trace for the above situation will start with one of the following errors:

refcount_t: decrement hit 0; leaking memory.
refcount_t: underflow; use-after-free.

And will then have a trace like:

Call Trace:
<TASK>
? show_regs+0x64/0x70
? __warn+0x83/0x120
? refcount_warn_saturate+0xb2/0x100
? report_bug+0x158/0x190
? prb_read_valid+0x20/0x30
? handle_bug+0x3e/0x70
? exc_invalid_op+0x1c/0x70
? asm_exc_invalid_op+0x1f/0x30
? refcount_warn_saturate+0xb2/0x100
? refcount_warn_saturate+0xb2/0x100
ax25_release+0x2ad/0x360
__sock_release+0x35/0xa0
sock_close+0x19/0x20
[...]

On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop:

unregister_netdevice: waiting for ax0 to become free. Usage count = 0

This patch corrects these issues by ensuring that we call netdevhold() and ax25devhold() for new connections in ax25accept(). This makes the logic leading to ax25accept() match the logic for ax25bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().(CVE-2024-40910)

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

KVM: Fix a data race on lastboostedvcpu in kvmvcpuon_spin()

Use {READ,WRITE}ONCE() to access kvm->lastboosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs:

CPU0 CPU1 lastboostedvcpu = 0xff;

                                (last_boosted_vcpu = 0x100)
                                last_boosted_vcpu[15:8] = 0x01;

i = (lastboostedvcpu = 0x1ff) lastboostedvcpu[7:0] = 0x00;

vcpu = kvm->vcpu_array[0x1ff];

As detected by KCSAN:

BUG: KCSAN: data-race in kvmvcpuonspin [kvm] / kvmvcpuonspin [kvm]

write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvmvcpuonspin (arch/x86/kvm/../../../virt/kvm/kvmmain.c:4112) kvm handlepause (arch/x86/kvm/vmx/vmx.c:5929) kvmintel vmxhandleexit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvmintel vcpurun (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvmarchvcpuioctlrun (arch/x86/kvm/x86.c:?) kvm kvmvcpuioctl (arch/x86/kvm/../../../virt/kvm/kvmmain.c:?) kvm _sesysioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) _x64sysioctl (fs/ioctl.c:890) x64syscall (arch/x86/entry/syscall64.c:33) dosyscall64 (arch/x86/entry/common.c:?) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvmvcpuonspin (arch/x86/kvm/../../../virt/kvm/kvmmain.c:4069) kvm handlepause (arch/x86/kvm/vmx/vmx.c:5929) kvmintel vmxhandleexit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvmintel vcpurun (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvmarchvcpuioctlrun (arch/x86/kvm/x86.c:?) kvm kvmvcpuioctl (arch/x86/kvm/../../../virt/kvm/kvmmain.c:?) kvm _sesysioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) _x64sysioctl (fs/ioctl.c:890) x64syscall (arch/x86/entry/syscall64.c:33) dosyscall64 (arch/x86/entry/common.c:?) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

value changed: 0x00000012 -> 0x00000000(CVE-2024-40953)

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

xfrm6: check ip6dstidev() return value in xfrm6getsaddr()

ip6dstidev() can return NULL, xfrm6getsaddr() must act accordingly.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wgpackethandshakesendworker RIP: 0010:xfrm6getsaddr+0x93/0x130 net/ipv6/xfrm6policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xfrmgetsaddr net/xfrm/xfrmpolicy.c:2452 [inline] xfrmtmplresolveone net/xfrm/xfrmpolicy.c:2481 [inline] xfrmtmplresolve+0xa26/0xf10 net/xfrm/xfrmpolicy.c:2541 xfrmresolveandcreatebundle+0x140/0x2570 net/xfrm/xfrmpolicy.c:2835 xfrmbundlelookup net/xfrm/xfrmpolicy.c:3070 [inline] xfrmlookupwithifid+0x4d1/0x1e60 net/xfrm/xfrmpolicy.c:3201 xfrmlookup net/xfrm/xfrmpolicy.c:3298 [inline] xfrmlookuproute+0x3b/0x200 net/xfrm/xfrmpolicy.c:3309 ip6dstlookupflow+0x15c/0x1d0 net/ipv6/ip6output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wgsocketsendskbtopeer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wgsocketsendbuffertopeer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wgpacketsendhandshakeinitiation+0x227/0x360 drivers/net/wireguard/send.c:40 wgpackethandshakesendworker+0x1c/0x30 drivers/net/wireguard/send.c:51 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)

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

ipv6: prevent possible NULL deref in fib6nhinit()

syzbot reminds us that in6devget() can return NULL.

fib6nhinit() ip6validategw( &idev ) ip6routechecknh( idev ) *idev = in6dev_get(dev); // can be NULL

Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:fib6nhinit+0x640/0x2160 net/ipv6/route.c:3606 Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b RSP: 0018:ffffc900032775a0 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8 RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000 R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8 R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000 FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip6routeinfocreate+0x99e/0x12b0 net/ipv6/route.c:3809 ip6routeadd+0x28/0x160 net/ipv6/route.c:3853 ipv6routeioctl+0x588/0x870 net/ipv6/route.c:4483 inet6ioctl+0x21a/0x280 net/ipv6/afinet6.c:579 sockdoioctl+0x158/0x460 net/socket.c:1222 sockioctl+0x629/0x8e0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:907 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f RIP: 0033:0x7f940f07cea9(CVE-2024-40961)

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

drm/lima: mask irqs in timeout path before hard reset

There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on limapmidle, with a stack dump such as:

[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/limadevfreq.c:205 limadevfreqrecordidle+0xa0/0xb0 ... [10136.669459] pc : limadevfreqrecordidle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] limadevfreqrecordidle+0xa0/0xb0 [10136.669646] limaschedpipetaskdone+0x5c/0xb0 [10136.669656] limagpirqhandler+0xa8/0x120 [10136.669666] _handleirqeventpercpu+0x48/0x160 [10136.669679] handleirq_event+0x4c/0xc0

We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler.(CVE-2024-40976)

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

drm/radeon: fix UBSAN warning in kv_dpm.c

Adds bounds check for sumovidmapping_entry.(CVE-2024-40988)

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

net: ena: Add validation for completion descriptors consistency

Validate that first flag is set only for the first descriptor in multi-buffer packets. In case of an invalid descriptor, a reset will occur. A new reset reason for RX data corruption has been added.(CVE-2024-40999)

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

netrom: Fix a memory leak in nrheartbeatexpiry()

syzbot reported a memory leak in nr_create() [0].

Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sockhold() to the nrheartbeatexpiry() function, where a) a socket has a SOCKDESTROY flag or b) a listening socket has a SOCK_DEAD flag.

But in the case "a," when the SOCKDESTROY flag is set, the file descriptor has already been closed and the nrrelease() function has been called. So it makes no sense to hold the reference count because no one will call another nrdestroysocket() and put it as in the case "b."

nrconnect nrestablishdatalink nrstartheartbeat

nrrelease switch (nr->state) case NRSTATE3 nr->state = NRSTATE2 socksetflag(sk, SOCKDESTROY);

                    nr_rx_frame
                      nr_process_rx_frame
                        switch (nr->state)
                        case NR_STATE_2
                          nr_state2_machine()
                            nr_disconnect()
                              nr_sk(sk)->state = NR_STATE_0
                              sock_set_flag(sk, SOCK_DEAD)

                    nr_heartbeat_expiry
                      switch (nr->state)
                      case NR_STATE_0
                        if (sock_flag(sk, SOCK_DESTROY) ||
                           (sk->sk_state == TCP_LISTEN
                             && sock_flag(sk, SOCK_DEAD)))
                           sock_hold()  // ( !!! )
                           nr_destroy_socket()

To fix the memory leak, let's call sock_hold() only for a listening socket.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.

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

xfs: don't walk off the end of a directory data block

This adds sanity checks for xfsdir2dataunused and xfsdir2dataentry to make sure don't stray beyond valid memory region. Before patching, the loop simply checks that the start offset of the dup and dep is within the range. So in a crafted image, if last entry is xfsdir2data_unused, we can change dup->length to dup->length-1 and leave 1 byte of space. In the next traversal, this space will be considered as dup or dep. We may encounter an out of bound read when accessing the fixed members.

In the patch, we make sure that the remaining bytes large enough to hold an unused entry before accessing xfsdir2dataunused and xfsdir2dataunused is XFSDIR2DATAALIGN byte aligned. We also make sure that the remaining bytes large enough to hold a dirent with a single-byte name before accessing xfsdir2dataentry.(CVE-2024-41013)

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

xfs: add bounds checking to xlogrecoverprocess_data

There is a lack of verification of the space occupied by fixed members of xlogopheader in the xlogrecoverprocess_data.

We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tailblk and headblk are the same, which will result in the inability to enter xlogrecoverprocessdata 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlogopheader entries only 1 byte away from xlogrecheader->hsize 5) xlogrecheader->hnumlogops++ 6) Modify xlogrecheader->h_crc

Fix: Add a check to make sure there is sufficient space to access fixed members of xlogopheader.(CVE-2024-41014)

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

fs/ntfs3: Validate ff offset

This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read.(CVE-2024-41019)

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

filelock: Fix fcntl/close race recovery compat path

When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport...

Apply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)

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

drm/amdgpu: Fix signedness bug in sdmav40processtrap_irq()

The "instance" variable needs to be signed for the error handling to work.(CVE-2024-41022)

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

sched/deadline: Fix task_struct reference leak

During the execution of the following stress test with linux-rt:

stress-ng --cyclic 30 --timeout 30 --minimize --quiet

kmemleak frequently reported a memory leak concerning the task_struct:

unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] duptaskstruct+0x30/0x540 [<00000000c5ca0f0b>] copyprocess+0x3d9/0x50e0 [<00000000ced59777>] kernelclone+0xb0/0x770 [<00000000a50befdc>] _dosysclone+0xb6/0xf0 [<000000001dbf2008>] dosyscall64+0x5d/0xf0 [<00000000552900ff>] entrySYSCALL64after_hwframe+0x6e/0x76

The issue occurs in startdltimer(), which increments the taskstruct reference count and sets a timer. The timer callback, dltasktimer, is supposed to decrement the reference count upon expiration. However, if enqueuetask_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak.

This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled.(CVE-2024-41023)

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

Fix userfaultfd_api to return EINVAL as expected

Currently if we request a feature that is not set in the Kernel config we fail silently and return all the available features. However, the man page indicates we should return an EINVAL.

We need to fix this issue since we can end up with a Kernel warning should a program request the feature UFFDFEATUREWP_UNPOPULATED on a kernel with the config not set with this feature.

[ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zappterange+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zappterange+0x43d/0x660(CVE-2024-41027)

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

net/sched: Fix UAF when resolving a clash

KASAN reports the following UAF:

BUG: KASAN: slab-use-after-free in tcfctflowtableprocessconn+0x12b/0x380 [actct] Read of size 1 at addr ffff888c07603600 by task handler130/6469

Call Trace: <IRQ> dumpstacklvl+0x48/0x70 printaddressdescription.constprop.0+0x33/0x3d0 printreport+0xc0/0x2b0 kasanreport+0xd0/0x120 _asanload1+0x6c/0x80 tcfctflowtableprocessconn+0x12b/0x380 [actct] tcfctact+0x886/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491 _irqexitrcu+0x82/0xc0 irqexitrcu+0xe/0x20 commoninterrupt+0xa1/0xb0 </IRQ> <TASK> asmcommon_interrupt+0x27/0x40

Allocated by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansaveallocinfo+0x1e/0x40 _kasankrealloc+0x133/0x190 krealloc+0xaa/0x130 nfctextadd+0xed/0x230 [nfconntrack] tcfctact+0x1095/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491

Freed by task 6469: kasansavestack+0x38/0x70 kasansettrack+0x25/0x40 kasansavefreeinfo+0x2b/0x60 __kasanslabfree+0x180/0x1f0 _kasanslabfree+0x12/0x30 slabfreefreelisthook+0xd2/0x1a0 _kmemcachefree+0x1a2/0x2f0 kfree+0x78/0x120 nfconntrackfree+0x74/0x130 [nfconntrack] nfctdestroy+0xb2/0x140 [nfconntrack] _nfctresolveclash+0x529/0x5d0 [nfconntrack] nfctresolveclash+0xf6/0x490 [nfconntrack] _nfconntrackconfirm+0x2c6/0x770 [nfconntrack] tcfctact+0x12ad/0x1350 [actct] tcfactionexec+0xf8/0x1f0 flclassify+0x355/0x360 [clsflower] _tcfclassify+0x1fd/0x330 tcfclassify+0x21c/0x3c0 schhandleingress.constprop.0+0x2c5/0x500 _netifreceiveskbcore.constprop.0+0xb25/0x1510 _netifreceiveskblistcore+0x220/0x4c0 netifreceiveskblistinternal+0x446/0x620 napicompletedone+0x157/0x3d0 grocellpoll+0xcf/0x100 _napipoll+0x65/0x310 netrxaction+0x30c/0x5c0 _dosoftirq+0x14f/0x491

The ct may be dropped if a clash has been resolved but is still passed to the tcfctflowtableprocess_conn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)

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

udp: Set SOCKRCUFREE earlier in udplibget_port().

syzkaller triggered the warning [0] in udpv4early_demux().

In udpv[46]earlydemux() and sklookup(), we do not touch the refcount of the looked-up sk and use sockpfree() as skb->destructor, so we check SOCKRCU_FREE to ensure that the sk is safe to access during the RCU grace period.

Currently, SOCKRCUFREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCKRCUFREE check is done too early in udpv[46]earlydemux() and sklookup(), so there could be a small race window:

CPU1 CPU2 ---- ---- udpv4earlydemux() udplibgetport() | |- hlistaddheadrcu() |- sk = _udp4libdemuxlookup() | |- DEBUGNETWARNONONCE(skisrefcounted(sk)); `- socksetflag(sk, SOCKRCU_FREE)

We had the same bug in TCP and fixed it in commit 871019b22d1b ("net: set SOCKRCUFREE before inserting socket into hashtable").

Let's apply the same fix for UDP.

Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udpv4earlydemux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> iprcvfinishcore.constprop.0+0xbdd/0xd20 net/ipv4/ipinput.c:349 iprcvfinish+0xda/0x150 net/ipv4/ipinput.c:447 NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] iprcv+0x16c/0x180 net/ipv4/ipinput.c:569 _netifreceiveskbonecore+0xb3/0xe0 net/core/dev.c:5624 _netifreceiveskb+0x21/0xd0 net/core/dev.c:5738 netifreceiveskbinternal net/core/dev.c:5824 [inline] netifreceiveskb+0x271/0x300 net/core/dev.c:5884 tunrxbatched drivers/net/tun.c:1549 [inline] tungetuser+0x24db/0x2c50 drivers/net/tun.c:2002 tunchrwriteiter+0x107/0x1a0 drivers/net/tun.c:2048 newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x76f/0x8d0 fs/readwrite.c:590 ksyswrite+0xbf/0x190 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x41/0x50 fs/readwrite.c:652 x64syscall+0xe66/0x1990 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4b/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R ---truncated---(CVE-2024-41041)

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

ppp: reject claimed-as-LCP but actually malformed packets

Since 'pppasyncencode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'pppcheckpacket()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)

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

skmsg: Skip zero length skb in skmsgrecvmsg

When running BPF selftests (./testprogs -t sockmapbasic) on a Loongarch platform, the following kernel panic occurs:

[...] Oops[#1]: CPU: 22 PID: 2824 Comm: testprogs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 skmsgrecvmsg+0x120/0x560 ERA: 9000000004162774 copypagetoiter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpftestmod(OE) xtCHECKSUM xtMASQUERADE xtconntrack Process testprogs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copypagetoiter+0x74/0x1c0 [<90000000048bf6c0>] skmsgrecvmsg+0x120/0x560 [<90000000049f2b90>] tcpbpfrecvmsgparser+0x170/0x4e0 [<90000000049aae34>] inetrecvmsg+0x54/0x100 [<900000000481ad5c>] sockrecvmsg+0x7c/0xe0 [<900000000481e1a8>] _sysrecvfrom+0x108/0x1c0 [<900000000481e27c>] sysrecvfrom+0x1c/0x40 [<9000000004c076ec>] dosyscall+0x8c/0xc0 [<9000000003731da4>] handlesyscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...]

This crash happens every time when running sockmapskbverdictshutdown subtest in sockmapbasic.

This crash is because a NULL pointer is passed to pageaddress() in the skmsgrecvmsg(). Due to the different implementations depending on the architecture, pageaddress(NULL) will trigger a panic on Loongarch platform but not on x86 platform. So this bug was hidden on x86 platform for a while, but now it is exposed on Loongarch platform. The root cause is that a zero length skb (skb->len == 0) was put on the queue.

This zero length skb is a TCP FIN packet, which was sent by shutdown(), invoked in testsockmapskbverdictshutdown():

shutdown(p1, SHUT_WR);

In this case, in skpsockskbingressenqueue(), numsge is zero, and no page is put to this sge (see sgsetpage in sgsetpage), but this empty sge is queued into ingressmsg list.

And in skmsgrecvmsg(), this empty sge is used, and a NULL page is got by sgpage(sge). Pass this NULL page to copypagetoiter(), which passes it to kmaplocalpage() and to page_address(), then kernel panics.

To solve this, we should skip this zero length skb. So in skmsgrecvmsg(), if copy is zero, that means it's a zero length skb, skip invoking copypagetoiter(). We are using the EFAULT return triggered by copypagetoiter to check for isfin in tcpbpf.c.(CVE-2024-41048)

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

filelock: fix potential use-after-free in posixlockinode

Light Hsieh reported a KASAN UAF warning in traceposixlock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock.

Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen.(CVE-2024-41049)

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

mm: prevent derefencing NULL ptr in pfnsectionvalid()

Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memorysection->usage") changed pfnsectionvalid() to add a READONCE() call around "ms->usage" to fix a race with sectiondeactivate() where ms->usage can be cleared. The READONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.(CVE-2024-41055)

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

bluetooth/l2cap: sync sock recv cb and release

The problem occurs between the system call to close the sock and hcirxwork, where the former releases the sock and the latter accesses it without lock protection.

       CPU0                       CPU1
       ----                       ----
       sock_close                 hci_rx_work
   l2cap_sock_release         hci_acldata_packet
   l2cap_sock_kill            l2cap_recv_frame
   sk_free                    l2cap_conless_channel
                              l2cap_sock_recv_cb

If hcirxwork processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data.

Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb.

Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.(CVE-2024-41062)

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

Bluetooth: hcicore: cancel all works upon hciunregister_dev()

syzbot is reporting that calling hcireleasedev() from hcierrorreset() due to hcidevput() from hcierrorreset() can cause deadlock at destroyworkqueue(), for hcierrorreset() is called from hdev->reqworkqueue which destroy_workqueue() needs to flush.

We need to make sure that hdev->{rxwork,cmdwork,txwork} which are queued into hdev->workqueue and hdev->{poweron,errorreset} which are queued into hdev->reqworkqueue are no longer running by the moment

   destroy_workqueue(hdev->workqueue);
   destroy_workqueue(hdev->req_workqueue);

are called from hcireleasedev().

Call cancelworksync() on these work items from hciunregisterdev() as soon as hdev->list is removed from hcidevlist.(CVE-2024-41063)

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

powerpc/eeh: avoid possible crash when edev->pdev changes

If a PCI device is removed during eehpereport_edev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.(CVE-2024-41064)

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

ibmvnic: Add tx check to prevent skb leak

Below is a summary of how the driver stores a reference to an skb during transmit: txbuff[freemap[consumerindex]]->skb = newskb; freemap[consumerindex] = IBMVNICINVALIDMAP; consumerindex ++; Where variable data looks like this: freemap == [4, IBMVNICINVALIDMAP, IBMVNICINVALIDMAP, 0, 3] consumerindex^ txbuff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null]

The driver has checks to ensure that freemap[consumerindex] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our freemap and txbuff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT.

Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)

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

ASoC: topology: Fix references to freed memory

Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)

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

KVM: PPC: Book3S HV: Prevent UAF in kvmspaprtceattachiommu_group()

Al reported a possible use-after-free (UAF) in kvmspaprtceattachiommu_group().

It looks up stt from tablefd, but then continues to use it after doing fdput() on the returned fd. After the fdput() the tablefd is free to be closed by another thread. The close calls kvmspaprtcerelease() and then releasespaprtcetable() (via call_rcu()) which frees stt.

Although there are calls to rcureadlock() in kvmspaprtceattachiommu_group() they are not sufficient to prevent the UAF, because stt is used outside the locked regions.

With an artifcial delay after the fdput() and a userspace program which triggers the race, KASAN detects the UAF:

BUG: KASAN: slab-use-after-free in kvmspaprtceattachiommugroup+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dumpstacklvl+0xb4/0x108 (unreliable) printreport+0x2b4/0x6ec kasanreport+0x118/0x2b0 _asanload4+0xb8/0xd0 kvmspaprtceattachiommugroup+0x298/0x720 [kvm] kvmvfiosetattr+0x524/0xac0 [kvm] kvmdeviceioctl+0x144/0x240 [kvm] sysioctl+0x62c/0x1810 systemcallexception+0x190/0x440 systemcallvectoredcommon+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 releasespaprtcetable+0xd4/0x11c [kvm] rcucore+0x568/0x16a0 handlesoftirqs+0x23c/0x920 dosoftirqownstack+0x6c/0x90 dosoftirqownstack+0x58/0x90 _irqexitrcu+0x218/0x2d0 irqexit+0x30/0x80 archlocalirqrestore+0x128/0x230 archlocalirqenable+0x1c/0x30 cpuidleenterstate+0x134/0x5cc cpuidleenter+0x6c/0xb0 callcpuidle+0x7c/0x100 doidle+0x394/0x410 cpustartupentry+0x60/0x70 startsecondary+0x3fc/0x410 startsecondaryprolog+0x10/0x14

Fix it by delaying the fdput() until stt is no longer in use, which is effectively the entire function. To keep the patch minimal add a call to fdput() at each of the existing return paths. Future work can convert the function to goto or __cleanup style cleanup.

With the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)

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

wifi: cfg80211: wext: add extra SIOCSIWSCAN data check

In 'cfg80211wextsiwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IWMAXFREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)

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

nvme: avoid double free special payload

If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQFSPECIALLOAD when the request is cleaned.(CVE-2024-41073)

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

null_blk: fix validation of block size

Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check.

Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1].

axboe: remove unnecessary braces and != 0 check

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

nvmet: always initialize cqe.result

The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA.

Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.(CVE-2024-41079)

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

iouring: fix possible deadlock in ioregisteriowqmax_workers()

The ioregisteriowqmaxworkers() function calls ioputsqdata(), which acquires the sqd->lock without releasing the uringlock. Similar to the commit 009ad9f0c6ee ("iouring: drop ctx->uringlock before acquiring sqd->lock"), this can lead to a potential deadlock situation.

To resolve this issue, the uringlock is released before calling ioputsqdata(), and then it is re-acquired after the function call.

This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock.(CVE-2024-41080)

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

ila: block BH in ila_output()

As explained in commit 1378817486d6 ("tipc: block BH before using dstcache"), net/core/dstcache.c helpers need to be called with BH disabled.

ilaoutput() is called from lwtunneloutput() possibly from process context, and under rcureadlock().

We might be interrupted by a softirq, re-enter ilaoutput() and corrupt dstcache data structures.

Fix the race by using localbhdisable().(CVE-2024-41081)

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

ata: libata-core: Fix double free on error

If e.g. the ataportalloc() call in atahostalloc() fails, we will jump to the errout label, which will call devresreleasegroup(). devresreleasegroup() will trigger a call to atahostrelease(). atahostrelease() calls kfree(host), so executing the kfree(host) in atahost_alloc() will lead to a double free:

kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? _diebody.cold+0x19/0x27 ? die+0x2e/0x50 ? dotrap+0xca/0x110 ? doerrortrap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? excinvalidop+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asmexcinvalidop+0x1a/0x20 ? atahostalloc+0xf5/0x120 [libata] ? atahostalloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 atahostalloc+0xf5/0x120 [libata] atahostallocpinfo+0x14/0xa0 [libata] ahciinit_one+0x6c9/0xd20 [ahci]

Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devresopengroup() call failed.(CVE-2024-41087)

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

drm/nouveau/dispnv04: fix null pointer dereference in nv17tvgethdmodes

In nv17tvgethdmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmodeduplicate(). The same applies to drmcvtmode(). Add a check to avoid null pointer dereference.(CVE-2024-41089)

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

tap: add missing verification for short frame

The cited commit missed to check against the validity of the frame length in the tapgetuserxdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tapgetuserxdp()-->skbsetnetworkheader() may assume the size is more than ETHHLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tapgetuser() already prohibits short frame which has the length less than Ethernet header size from being transmitted.

This is to drop any frame shorter than the Ethernet header size just like how tapgetuser() does.

CVE: CVE-2024-41090(CVE-2024-41090)

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

tun: add missing verification for short frame

The cited commit missed to check against the validity of the frame length in the tunxdpone() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tunxdpone-->ethtypetrans() may access the Ethernet header although it can be less than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tungetuser() already prohibits short frame which has the length less than Ethernet header size from being transmitted for IFF_TAP.

This is to drop any frame shorter than the Ethernet header size just like how tungetuser() does.

CVE: CVE-2024-41091(CVE-2024-41091)

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

usb: atm: cxacru: fix endpoint checking in cxacru_bind()

Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usbsubmiturb().

Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type.

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

[1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usbhubwq hubevent RIP: 0010:usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacrucm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacrucardstatus+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacrubind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatmusbprobe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacruusbprobe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usbprobeinterface+0x315/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:517 [inline] reallyprobe+0x23c/0xcd0 drivers/base/dd.c:595 _driverprobedevice+0x338/0x4d0 drivers/base/dd.c:747 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:777 _deviceattachdriver+0x20b/0x2f0 drivers/base/dd.c:894 busforeachdrv+0x15f/0x1e0 drivers/base/bus.c:427 _deviceattach+0x228/0x4a0 drivers/base/dd.c:965 busprobedevice+0x1e4/0x290 drivers/base/bus.c:487 deviceadd+0xc2f/0x2180 drivers/base/core.c:3354 usbsetconfiguration+0x113a/0x1910 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xba/0x100 drivers/usb/core/generic.c:238 usbprobe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293(CVE-2024-41097)

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

bpf: Take return from setmemoryro() into account with bpfproglock_ro()

setmemoryro() can fail, leaving memory unprotected.

Check its return and take it into account as an error.(CVE-2024-42068)

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

net: can: j1939: Initialize unused data in j1939sendone()

syzbot reported kernel-infoleak in rawrecvmsg() [1]. j1939send_one() creates full frame including unused data, but it doesn't initialize it. This causes the kernel-infoleak issue. Fix this by initializing unused data.

[1] BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copytoiter+0x366/0x2520 lib/ioviter.c:185 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouseriter lib/ioviter.c:24 [inline] iterateubuf include/linux/ioviter.h:29 [inline] iterateandadvance2 include/linux/ioviter.h:245 [inline] iterateandadvance include/linux/ioviter.h:271 [inline] _copytoiter+0x366/0x2520 lib/ioviter.c:185 copytoiter include/linux/uio.h:196 [inline] memcpytomsg include/linux/skbuff.h:4113 [inline] rawrecvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x2c4/0x340 net/socket.c:1068 _sysrecvmsg+0x18a/0x620 net/socket.c:2803 sysrecvmsg+0x223/0x840 net/socket.c:2845 dorecvmmsg+0x4fc/0xfd0 net/socket.c:2939 _sysrecvmmsg net/socket.c:3018 [inline] _dosysrecvmmsg net/socket.c:3041 [inline] _sesysrecvmmsg net/socket.c:3034 [inline] _x64sysrecvmmsg+0x397/0x490 net/socket.c:3034 x64syscall+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls64.h:300 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x613/0xc50 mm/slub.c:3888 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:577 allocskb+0x35b/0x7a0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1313 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6504 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2795 sockallocsendskb include/net/sock.h:1842 [inline] j1939skallocskb net/can/j1939/socket.c:878 [inline] j1939sksendloop net/can/j1939/socket.c:1142 [inline] j1939sksendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 syssendmsg+0x877/0xb60 net/socket.c:2584 _syssendmsg+0x28d/0x3c0 net/socket.c:2638 _syssendmsg net/socket.c:2667 [inline] _dosyssendmsg net/socket.c:2676 [inline] _sesyssendmsg net/socket.c:2674 [inline] _x64syssendmsg+0x307/0x4a0 net/socket.c:2674 x64syscall+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at ffff888120969690 Data copied to user address 00000000200017c0

CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)

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

ocfs2: fix DIO failure due to insufficient transaction credits

The code in ocfs2dioendiowrite() estimates number of necessary transaction credits using ocfs2calcextend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents.

Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2markextentwritten() will end up calling ocfs2replaceextentrec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARNON(jbd2handlebuffercredits(handle) <= 0) is triggered in jbd2journaldirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem.

To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2markextent_written().

Heming Zhao said:

PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"

PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machinekexec at ffffffff8c069932 #1 _crashkexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2handleerror at ffffffffc0c86c0c [ocfs2] #4 _ocfs2abort at ffffffffc0c88387 [ocfs2] #5 ocfs2journaldirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2splitextent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2changeextentflag at ffffffffc0c28053 [ocfs2] #8 ocfs2markextentwritten at ffffffffc0c28347 [ocfs2] #9 ocfs2dioendio_write at ffffffffc0c2bef9 [ocfs2]

10 ocfs2dioend_io at ffffffffc0c2c0f5 [ocfs2]

11 dio_complete at ffffffff8c2b9fa7

12 doblockdevdirect_IO at ffffffff8c2bc09f

13 ocfs2directIO at ffffffffc0c2b653 [ocfs2]

14 genericfiledirect_write at ffffffff8c1dcf14

15 _genericfilewriteiter at ffffffff8c1dd07b

16 ocfs2filewrite_iter at ffffffffc0c49f1f [ocfs2]

17 aio_write at ffffffff8c2cc72e

18 kmemcachealloc at ffffffff8c248dde

19 doiosubmit at ffffffff8c2ccada

20 dosyscall64 at ffffffff8c004984

21 entrySYSCALL64afterhwframe at ffffffff8c8000ba(CVE-2024-42077)

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

RDMA/restrack: Fix potential invalid address access

struct rdmarestrackentry's kernname was set to KBUILDMODNAME in ibcreatecq(), while if the module exited but forgot del this rdmarestrackentry, it would cause a invalid address access in rdmarestrackclean() when print the owner of this rdmarestrackentry.

These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)

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

xdp: Remove WARN() from _xdpregmemmodel()

syzkaller reports a warning in _xdpregmemmodel().

The warning occurs only if _memidinithash_table() returns an error. It returns the error in two cases:

1. memory allocation fails;
2. rhashtableinit() fails when some fields of rhashtableparams struct are not initialized properly.

The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation.

Thus, there is no sense in using WARN() to handle this error and it can be safely removed.

WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 _xdpregmemmodel+0x2d9/0x650 net/core/xdp.c:299

CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:_xdpregmemmodel+0x2d9/0x650 net/core/xdp.c:299

Call Trace: xdpregmemmodel+0x22/0x40 net/core/xdp.c:344 xdptestrunsetup net/bpf/testrun.c:188 [inline] bpftestrunxdplive+0x365/0x1e90 net/bpf/testrun.c:377 bpfprogtestrunxdp+0x813/0x11b0 net/bpf/testrun.c:1267 bpfprogtestrun+0x33a/0x3b0 kernel/bpf/syscall.c:4240 _sysbpf+0x48d/0x810 kernel/bpf/syscall.c:5649 _dosysbpf kernel/bpf/syscall.c:5738 [inline] _sesysbpf kernel/bpf/syscall.c:5736 [inline] _x64sysbpf+0x7c/0x90 kernel/bpf/syscall.c:5736 dosyscall64+0xfb/0x240 entrySYSCALL64after_hwframe+0x6d/0x75

Found by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)

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

ftruncate: pass a signed offset

The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB.

Changing the type of the compat syscall to the signed compatofft changes the behavior so it instead returns -EINVAL.

The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake.(CVE-2024-42084)

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

iio: chemical: bme680: Fix overflows in compensate() functions

There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor").

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

ASoC: fsl-asoc-card: set priv->pdev before using it

priv->pdev pointer was set after being used in fslasoccardaudmuxinit(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv.

fslasoccardaudmuxinit() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations.(CVE-2024-42089)

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

pinctrl: fix deadlock in createpinctrl() when handling -EPROBEDEFER

In createpinctrl(), pinctrlmapsmutex is acquired before calling addsetting(). If addsetting() returns -EPROBEDEFER, createpinctrl() calls pinctrlfree(). However, pinctrlfree() attempts to acquire pinctrlmapsmutex, which is already held by createpinctrl(), leading to a potential deadlock.

This patch resolves the issue by releasing pinctrlmapsmutex before calling pinctrl_free(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)

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

gpio: davinci: Validate the obtained number of IRQs

Value of pdata->gpiounbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davincigpio_probe().

Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)

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

net/dpaa2: Avoid explicit cpumask var allocation on stack

For CONFIGCPUMASKOFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.

Instead, kernel code should always use *cpumaskvar API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIGCPUMASK_OFFSTACK.

Use *cpumask_var API(s) to address it.(CVE-2024-42093)

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

net/iucv: Avoid explicit cpumask var allocation on stack

For CONFIGCPUMASKOFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow.

Instead, kernel code should always use *cpumaskvar API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIGCPUMASK_OFFSTACK.

Use *cpumask_var API(s) to address it.(CVE-2024-42094)

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

ALSA: emux: improve patch ioctl data validation

In loaddata(), make the validation of and skipping over the main info block match that in loadguspatch().

In loadguspatch(), add checking that the specified patch length matches the actually supplied data, like loaddata() already did.(CVE-2024-42097)

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

drm/nouveau: fix null pointer dereference in nouveauconnectorget_modes

In nouveauconnectorgetmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)

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

inetdiag: Initialize pad field in struct inetdiagreqv2

KMSAN reported uninit-value access in rawlookup() [1]. Diag for raw sockets uses the pad field in struct inetdiagreqv2 for the underlying protocol. This field corresponds to the sdiagrawprotocol field in struct inetdiagreq_raw.

inetdiaggetexactcompat() converts inetdiagreq to inetdiagreqv2, but leaves the pad field uninitialized. So the issue occurs when rawlookup() accesses the sdiagrawprotocol field.

Fix this by initializing the pad field in inetdiaggetexactcompat(). Also, do the same fix in inetdiagdump_compat() to avoid the similar issue in the future.

[1] BUG: KMSAN: uninit-value in rawlookup net/ipv4/rawdiag.c:49 [inline] BUG: KMSAN: uninit-value in rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawlookup net/ipv4/rawdiag.c:49 [inline] rawsockget+0x657/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 _syssendmsg+0x7f0/0xb70 net/socket.c:2585 _syssendmsg+0x271/0x3b0 net/socket.c:2639 _syssendmsg net/socket.c:2668 [inline] _dosyssendmsg net/socket.c:2677 [inline] _sesyssendmsg net/socket.c:2675 [inline] _x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was stored to memory at: rawsockget+0x650/0x800 net/ipv4/rawdiag.c:71 rawdiagdumpone+0xa1/0x660 net/ipv4/rawdiag.c:99 inetdiagcmdexact+0x7d9/0x980 inetdiaggetexactcompat net/ipv4/inetdiag.c:1404 [inline] inetdiagrcvmsgcompat+0x469/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282 netlinkrcvskb+0x537/0x670 net/netlink/afnetlink.c:2564 sockdiagrcv+0x35/0x40 net/core/sockdiag.c:297 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xe74/0x1240 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10c6/0x1260 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x332/0x3d0 net/socket.c:745 syssendmsg+0x7f0/0xb70 net/socket.c:2585 _syssendmsg+0x271/0x3b0 net/socket.c:2639 _syssendmsg net/socket.c:2668 [inline] _dosyssendmsg net/socket.c:2677 [inline] _sesyssendmsg net/socket.c:2675 [inline] _x64syssendmsg+0x27e/0x4a0 net/socket.c:2675 x64syscall+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd9/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable req.i created at: inetdiaggetexactcompat net/ipv4/inetdiag.c:1396 [inline] inetdiagrcvmsgcompat+0x2a6/0x530 net/ipv4/inetdiag.c:1426 sockdiagrcvmsg+0x23d/0x740 net/core/sockdiag.c:282

CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)

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

jffs2: Fix potential illegal address access in jffs2freeinode

During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2freeinode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2freeinode+0x24/0x48 [ 2430.665233] icallback+0x24/0x50 [ 2430.665528] rcudobatch+0x1ac/0x448 [ 2430.665892] rcucore+0x28c/0x3c8 [ 2430.666151] rcucoresi+0x18/0x28 [ 2430.666473] _dosoftirq+0x138/0x3cc [ 2430.666781] irqexit+0xf0/0x110 [ 2430.667065] handledomainirq+0x6c/0x98 [ 2430.667447] gichandleirq+0xac/0xe8 [ 2430.667739] callonirqstack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffsinodeinfo structure. It was found that all variables in the jffsinodeinfo structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2iinitonce, while other members are initialized in the function jffs2initinodeinfo.

The function jffs2initinodeinfo is called after igetlocked, but in the igetlocked function, the destroyinode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, igetlocked may enter the destroyinode branch as described in the code.

Since the destroyinode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2iinitonce.(CVE-2024-42115)

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

scsi: qedf: Make qedfexecutetmf() non-preemptible

Stop calling smpprocessorid() from preemptible code in qedfexecutetmf90. This results in BUG_ON() when running an RT kernel.

[ 659.343280] BUG: using smpprocessorid() in preemptible [00000000] code: sgreset/3646 [ 659.343282] caller is qedfexecute_tmf+0x8b/0x360 qedf

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

leds: mlxreg: Use devmmutexinit() for mutex initialization

In this driver LEDs are registered using devmledclassdevregister() so they are automatically unregistered after module's remove() is done. ledclassdevunregister() calls module's ledset_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.(CVE-2024-42129)

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

Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot

Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue:

BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390.

The commit is to fix a use-after-free issue within qcaserdevshutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot.

Fixed by sending the VSC to reset controller within qcaserdevshutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote.

Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree.(CVE-2024-42137)

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

IB/core: Implement a limit on UMAD receive List

The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow.

To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space.

Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.(CVE-2024-42145)

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

s390/pkey: Wipe copies of protected- and secure-keys

Although the clear-key of neither protected- nor secure-keys is accessible, this key material should only be visible to the calling process. So wipe all copies of protected- or secure-keys from stack, even in case of an error.(CVE-2024-42155)

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

f2fs: check validation of fault attrs in f2fsbuildfault_attr()

• It missed to check validation of fault attrs in parseoptions(), let's fix to add check condition in f2fsbuildfaultattr().
• Use f2fsbuildfaultattr() in _sbi_store() to clean up code.(CVE-2024-42160)

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

bpf: Avoid uninitialized value in BPFCOREREAD_BITFIELD

[Changes from V1: - Use a default branch in the switch statement to initialize `val'.]

GCC warns that `val' may be used uninitialized in the BPFCREREADBITFIELD macro, defined in bpfcore_read.h as:

[...]
unsigned long long val;                           \
[...]                                     \
switch (__CORE_RELO(s, field, BYTE_SIZE)) {               \
case 1: val = *(const unsigned char *)p; break;               \
case 2: val = *(const unsigned short *)p; break;              \
case 4: val = *(const unsigned int *)p; break;                \
case 8: val = *(const unsigned long long *)p; break;              \
    }                                         \
[...]
val;                                      \
}                                     \

This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case _builtinpreservefieldinfo returns unexpected values for BPFFIELDBYTE_SIZE.

Tested in bpf-next master. No regressions.(CVE-2024-42161)

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

gve: Account for stopped queues when reading NIC stats

We now account for the fact that the NIC might send us stats for a subset of queues. Without this change, gvegetethtoolstats might make an invalid access on the priv->statsreport->stats array.(CVE-2024-42162)

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

net: dsa: mv88e6xxx: Correct check for empty list

Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxxdefaultmdiobus() has checked that the return value of listfirst_entry() is non-NULL.

This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of listfirstentry is not designed to return NULL for empty lists.

Instead, use listfirstentryornull() which does return NULL if the list is empty.

Flagged by Smatch. Compile tested only.(CVE-2024-42224)

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

drm/amdgpu: Using uninitialized value *size when calling amdgpuvcecs_reloc

Initialize the size before calling amdgpuvcecs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)(CVE-2024-42228)