The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

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:

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:

serial: imx: Introduce timeout when waiting on transmitter empty

By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock.

In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue.(CVE-2024-40967)

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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)