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:

ALSA: scarlett2: Add clamp() in scarlett2mixerctl_put()

Ensure the value passed to scarlett2mixerctlput() is between 0 and SCARLETT2MIXERMAXVALUE so we don't attempt to access outside scarlett2mixervalues[].(CVE-2023-52674)

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

media: gspca: cpia1: shift-out-of-bounds in set_flicker

Syzkaller reported the following issue: UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27 shift exponent 245 is too large for 32-bit type 'int'

When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added.(CVE-2023-52764)

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:

selinux: avoid dereference of garbage after mount failure

In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer.

While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)

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/amdgpu: add error handle to avoid out-of-bounds

if the sdmav40irqidtoseq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)

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:

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:

ssb: Fix potential NULL pointer dereference in ssbdeviceuevent()

The ssbdeviceuevent() function first attempts to convert the 'dev' pointer to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before performing the NULL check, potentially leading to a NULL pointer dereference if 'dev' is NULL.

To fix this issue, move the NULL check before dereferencing the 'dev' pointer, ensuring that the pointer is valid before attempting to use it.

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

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:

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:

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:

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:

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:

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:

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)