The Linux Kernel, the operating system core itself.

Security Fix(es):

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

media: lgdt3306a: Add a check against null-pointer-def

The driver should check whether the client provides the platform_data.

The following log reveals it:

[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dumpstacklvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] printreport.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasanreport+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasancheckrange+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306aprobe+0x52/0x310 [ 29.616339] i2cdevice_probe+0x951/0xa90(CVE-2022-48772)

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

genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline

The absence of IRQDMOVEPCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.

When the interrupt next triggers on the original CPU, the new affinity is enforced within _irqmoveirq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->movein_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU, irqcompletemove() adds a task to the old CPU's vectorcleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vectorcleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.

In that case irqforcecompletemove() is not invoked on the outgoing CPU to reclaim the old apicd->prevvector because the interrupt isn't currently affine to the outgoing CPU, and irqneedsfixup() returns false. Even though _vectorschedulecleanup() is later called on the new CPU, it doesn't reclaim apicd->prevvector; instead, it simply resets both apicd->moveinprogress and apicd->prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak.

To address this issue, move the invocation of irqforcecompletemove() before the irqneedsfixup() call to reclaim apicd->prevvector, if the interrupt is currently or used to be affine to the outgoing CPU.

Additionally, reclaim the vector in _vectorschedulecleanup() as well, following a warning message, although theoretically it should never see apicd->moveinprogress with apicd->prevcpu pointing to an offline CPU.(CVE-2024-31076)

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

tls: fix missing memory barrier in tls_init

In tlsinit(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls{setsockopt,getsockopt}.

CPU0 CPU1 ----- ----- // In tlsinit() // In tlsctxcreate() ctx = kzalloc() ctx->skproto = READONCE(sk->skprot) -(1)

// In updateskprot() WRITEONCE(sk->skprot, tls_prots) -(2)

                               // In sock_common_setsockopt()
                               READ_ONCE(sk->sk_prot)->setsockopt()

                               // In tls_{setsockopt,getsockopt}()
                               ctx->sk_proto->setsockopt()    -(3)

In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference.

To fix it, we rely on rcuassignpointer() which implies the release barrier semantic. By moving rcuassignpointer() after ctx->skproto is initialized, we can ensure that ctx->skproto are visible when changing sk->sk_prot.(CVE-2024-36489)

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

amd/amdkfd: sync all devices to wait all processes being evicted

If there are more than one device doing reset in parallel, the first device will call kfdsuspendall_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.(CVE-2024-36949)

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

scsi: lpfc: Move NPIV's transport unregistration to after resource clean up

There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.

Currently fcremovehost(), which calls devlosstmo for all DIDs including the fabric DID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.

Fix by moving the fcremovehost() and scsiremovehost() calls after DA_ID and LOGO are sent.(CVE-2024-36952)

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

net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs

Currently the driver uses localbhdisable()/localbhenable() in its IRQ handler to avoid triggering netrxaction() softirq on exit from netifrx(). The netrxaction() could trigger this driver .startxmit callback, which is protected by the same lock as the IRQ handler, so calling the .startxmit from netifrx() from the IRQ handler critical section protected by the lock could lead to an attempt to claim the already claimed lock, and a hang.

The localbhdisable()/localbhenable() approach works only in case the IRQ handler is protected by a spinlock, but does not work if the IRQ handler is protected by mutex, i.e. this works for KS8851 with Parallel bus interface, but not for KS8851 with SPI bus interface.

Remove the BH manipulation and instead of calling netifrx() inside the IRQ handler code protected by the lock, queue all the received SKBs in the IRQ handler into a queue first, and once the IRQ handler exits the critical section protected by the lock, dequeue all the queued SKBs and push them all into netifrx(). At this point, it is safe to trigger the netrxaction() softirq, since the netif_rx() call is outside of the lock that protects the IRQ handler.(CVE-2024-36962)

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

remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well.

Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic.

To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core).(CVE-2024-36965)

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

virtio: delete vq in vpfindvqsmsix() when requestirq() fails

When requestirq() fails, error path calls vpdelvqs(). There, as vq is present in the list, freeirq() is called for the same vector. That causes following splat:

[ 0.414355] Trying to free already-free IRQ 27 [ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 freeirq+0x1a1/0x2d0 [ 0.414510] Modules linked in: [ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27 [ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 [ 0.414540] RIP: 0010:freeirq+0x1a1/0x2d0 [ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40 [ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086 [ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000 [ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001 [ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001 [ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760 [ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600 [ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000 [ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0 [ 0.414540] Call Trace: [ 0.414540] <TASK> [ 0.414540] ? warn+0x80/0x120 [ 0.414540] ? freeirq+0x1a1/0x2d0 [ 0.414540] ? reportbug+0x164/0x190 [ 0.414540] ? handlebug+0x3b/0x70 [ 0.414540] ? excinvalidop+0x17/0x70 [ 0.414540] ? asmexcinvalidop+0x1a/0x20 [ 0.414540] ? freeirq+0x1a1/0x2d0 [ 0.414540] vpdelvqs+0xc1/0x220 [ 0.414540] vpfindvqsmsix+0x305/0x470 [ 0.414540] vpfindvqs+0x3e/0x1a0 [ 0.414540] vpmodernfindvqs+0x1b/0x70 [ 0.414540] initvqs+0x387/0x600 [ 0.414540] virtnetprobe+0x50a/0xc80 [ 0.414540] virtiodevprobe+0x1e0/0x2b0 [ 0.414540] reallyprobe+0xc0/0x2c0 [ 0.414540] ? _pfxdriverattach+0x10/0x10 [ 0.414540] _driverprobedevice+0x73/0x120 [ 0.414540] driverprobedevice+0x1f/0xe0 [ 0.414540] _driverattach+0x88/0x180 [ 0.414540] busforeachdev+0x85/0xd0 [ 0.414540] busadddriver+0xec/0x1f0 [ 0.414540] driverregister+0x59/0x100 [ 0.414540] ? _pfxvirtionetdriverinit+0x10/0x10 [ 0.414540] virtionetdriverinit+0x90/0xb0 [ 0.414540] dooneinitcall+0x58/0x230 [ 0.414540] kernelinitfreeable+0x1a3/0x2d0 [ 0.414540] ? _pfxkernelinit+0x10/0x10 [ 0.414540] kernelinit+0x1a/0x1c0 [ 0.414540] retfromfork+0x31/0x50 [ 0.414540] ? _pfxkernelinit+0x10/0x10 [ 0.414540] retfromforkasm+0x1a/0x30 [ 0.414540] </TASK>

Fix this by calling deleting the current vq when request_irq() fails.(CVE-2024-37353)

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

btrfs: fix crash on racing fsync and size-extending write into prealloc

We have been seeing crashes on duplicate keys in btrfssetitemkeysafe():

BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfsio Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfssetitemkey_safe+0x11f/0x290 [btrfs]

With the following stack trace:

#0 btrfssetitemkeysafe (fs/btrfs/ctree.c:2620:4) #1 btrfsdropextents (fs/btrfs/file.c:411:4) #2 logoneextent (fs/btrfs/tree-log.c:4732:9) #3 btrfslogchangedextents (fs/btrfs/tree-log.c:4955:9) #4 btrfsloginode (fs/btrfs/tree-log.c:6626:9) #5 btrfsloginodeparent (fs/btrfs/tree-log.c:7070:8) #6 btrfslogdentrysafe (fs/btrfs/tree-log.c:7171:8) #7 btrfssyncfile (fs/btrfs/file.c:1933:8) #8 vfsfsyncrange (fs/sync.c:188:9) #9 vfsfsync (fs/sync.c:202:9) #10 dofsync (fs/sync.c:212:9) #11 _dosysfdatasync (fs/sync.c:225:9) #12 _sesysfdatasync (fs/sync.c:223:1) #13 _x64sysfdatasync (fs/sync.c:223:1) #14 dosyscallx64 (arch/x86/entry/common.c:52:14) #15 dosyscall64 (arch/x86/entry/common.c:83:7) #16 entrySYSCALL64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)

So we're logging a changed extent from fsync, which is splitting an extent in the log tree. But this split part already exists in the tree, triggering the BUG().

This is the state of the log tree at the time of the crash, dumped with drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfstree.py) to get more details than btrfsprint_leaf() gives us:

>>> printextentbuffer(prog.crashedthread().stacktrace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODEITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODEREF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTRITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 datalen 1 namelen 6 name: user.a data a item 3 key (450 EXTENTDATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENTDATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENTDATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ...

So the real problem happened earlier: notice that items 4 (4k-12k) and 5 (8k-12k) overlap. Both are prealloc extents. Item 4 straddles isize and item 5 starts at isize.

Here is the state of ---truncated---(CVE-2024-37354)

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

tcp: Fix shift-out-of-bounds in dctcpupdatealpha().

In dctcpupdatealpha(), we use a module parameter dctcpshiftg as follows:

alpha -= minnotzero(alpha, alpha >> dctcpshiftg); ... deliveredce <<= (10 - dctcpshift_g);

It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcpshiftg:

memcpy((void)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(NR_openat, /fd=/0xffffffffffffff9cul, /file=/0x20000080ul, /flags=/2ul, /mode=/0ul); memcpy((void)0x20000000, "100\000", 4); syscall(NR_write, /fd=/r[0], /val=/0x20000000ul, /len=/4ul);

Let's limit the max value of dctcpshiftg by paramsetuint_minmax().

With this patch:

# echo 10 > /sys/module/tcpdctcp/parameters/dctcpshiftg # cat /sys/module/tcpdctcp/parameters/dctcpshiftg 10 # echo 11 > /sys/module/tcpdctcp/parameters/dctcpshift_g -bash: echo: write error: Invalid argument

shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x201/0x300 lib/dumpstack.c:114 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleshiftoutofbounds+0x346/0x3a0 lib/ubsan.c:468 dctcpupdatealpha+0x540/0x570 net/ipv4/tcpdctcp.c:143 tcpinackevent net/ipv4/tcpinput.c:3802 [inline] tcpack+0x17b1/0x3bc0 net/ipv4/tcpinput.c:3948 tcprcvstateprocess+0x57a/0x2290 net/ipv4/tcpinput.c:6711 tcpv4dorcv+0x764/0xc40 net/ipv4/tcpipv4.c:1937 skbacklogrcv include/net/sock.h:1106 [inline] _releasesock+0x20f/0x350 net/core/sock.c:2983 releasesock+0x61/0x1f0 net/core/sock.c:3549 mptcpsubflowshutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcpchecksenddatafin+0x225/0x410 net/mptcp/protocol.c:2976 _mptcpclose+0x238/0xad0 net/mptcp/protocol.c:3072 mptcpclose+0x2a/0x1a0 net/mptcp/protocol.c:3127 inetrelease+0x190/0x1f0 net/ipv4/afinet.c:437 _sockrelease net/socket.c:659 [inline] sockclose+0xc0/0x240 net/socket.c:1421 _fput+0x41b/0x890 fs/filetable.c:422 taskworkrun+0x23b/0x300 kernel/taskwork.c:180 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x9c8/0x2540 kernel/exit.c:878 dogroupexit+0x201/0x2b0 kernel/exit.c:1027 _dosysexitgroup kernel/exit.c:1038 [inline] _sesysexitgroup kernel/exit.c:1036 [inline] _x64sysexitgroup+0x3f/0x40 kernel/exit.c:1036 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xe4/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>(CVE-2024-37356)

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

ASoC: mediatek: Assign dummy when codec not specified for a DAI link

MediaTek sound card drivers are checking whether a DAI link is present and used on a board to assign the correct parameters and this is done by checking the codec DAI names at probe time.

If no real codec is present, assign the dummy codec to the DAI link to avoid NULL pointer during string comparison.(CVE-2024-38551)

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

drm/amd/display: Fix potential index out of bounds in color transformation function

Fixes index out of bounds issue in the color transformation function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFERFUNCPOINTS).

The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, an error message is logged and the function returns false to indicate an error.

Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:405 cmhelpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:406 cmhelpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10cmcommon.c:407 cmhelpertranslatecurvetohwformat() error: buffer overflow 'outputtf->tfpts.blue' 1025 <= s32max(CVE-2024-38552)

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

ax25: Fix reference count leak issue of net_device

There is a reference count leak issue of the object "netdevice" in ax25devdevicedown(). When the ax25 device is shutting down, the ax25devdevicedown() drops the reference count of netdevice one or zero times depending on if we goto unlock_put or not, which will cause memory leak.

In order to solve the above issue, decrease the reference count of netdevice after dev->ax25ptr is set to null.(CVE-2024-38554)

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

net/mlx5: Discard command completions in internal error

Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.

Kernel log: ------------[ cut here ]------------ refcountt: underflow; use-after-free. ... RIP: 0010:refcountwarnsaturate+0xd8/0xe0 ... Call Trace: <IRQ> ? _warn+0x79/0x120 ? refcountwarnsaturate+0xd8/0xe0 ? reportbug+0x17c/0x190 ? handlebug+0x3c/0x60 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0xd8/0xe0 cmdentput+0x13b/0x160 [mlx5core] mlx5cmdcomphandler+0x5f9/0x670 [mlx5core] cmdcompnotifier+0x1f/0x30 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 mlx5eqasyncint+0xf6/0x290 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 irqinthandler+0x19/0x30 [mlx5core] _handleirqeventpercpu+0x4b/0x160 handleirqevent+0x2e/0x80 handleedgeirq+0x98/0x230 _commoninterrupt+0x3b/0xa0 commoninterrupt+0x7b/0xa0 </IRQ> <TASK> asmcommon_interrupt+0x22/0x40(CVE-2024-38555)

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

wifi: nl80211: Avoid address calculations via out of bounds array indexing

Before request->channels[] can be used, request->n_channels must be set. Additionally, address calculations for memory after the "channels" array need to be calculated from the allocation base ("request") rather than via the first "out of bounds" index of "channels", otherwise run-time bounds checking will throw a warning.(CVE-2024-38562)

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

bpf: Add BPFPROGTYPECGROUPSKB attach type enforcement in BPFLINKCREATE

bpfprogattach uses attachtypetoprogtype to enforce proper attach type for BPFPROGTYPECGROUPSKB. linkcreate uses bpfprogget and relies on bpfprogattachcheckattachtype to properly verify progtype <> attachtype association.

Add missing attachtype enforcement for the linkcreate case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks.(CVE-2024-38564)

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

rcu-tasks: Fix showrcutaskstracegp_kthread buffer overflow

There is a possibility of buffer overflow in showrcutaskstracegp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible.

Use snprintf() with buffer size instead of sprintf().

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

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

crypto: bcm - Fix pointer arithmetic

In spu2dumpomd() value of ptr is increased by ciphkeylen instead of hashivlen which could lead to going beyond the buffer boundaries. Fix this bug by changing ciphkeylen to hashivlen.

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

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

nilfs2: fix potential hang in nilfsdetachlog_writer()

Syzbot has reported a potential hang in nilfsdetachlog_writer() called during nilfs2 unmount.

Analysis revealed that this is because nilfssegctorsync(), which synchronizes with the log writer thread, can be called after nilfssegctordestroy() terminates that thread, as shown in the call trace below:

nilfsdetachlogwriter nilfssegctordestroy nilfssegctorkillthread --> Shut down log writer thread flushwork nilfsiputworkfunc nilfsdisposelist iput nilfsevictinode nilfstransactioncommit nilfsconstructsegment (if inode needs sync) nilfssegctorsync --> Attempt to synchronize with log writer thread * DEADLOCK *

Fix this issue by changing nilfssegctorsync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates.

The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfssegctordestroy().(CVE-2024-38582)

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

ftrace: Fix possible use-after-free issue in ftrace_location()

KASAN reports a bug:

BUG: KASAN: use-after-free in ftracelocation+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dumpstacklvl+0x68/0xa0 printreport+0xcf/0x610 kasanreport+0xb5/0xe0 ftracelocation+0x90/0x120 registerkprobe+0x14b/0xa40 kprobeinit+0x2d/0xff0 [kprobeexample] dooneinitcall+0x8f/0x2d0 doinitmodule+0x13a/0x3c0 loadmodule+0x3082/0x33d0 initmodulefromfile+0xd2/0x130 _x64sysfinitmodule+0x306/0x440 dosyscall64+0x68/0x140 entrySYSCALL64after_hwframe+0x71/0x79

The root cause is that, in lookuprec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftracerelease_mod() as the corresponding module is being deleted:

       CPU1                       |      CPU2

registerkprobes() { | deletemodule() { checkkprobeaddresssafe() { | archcheckftracelocation() { | ftracelocation() { | lookuprec() // USE! | ftracereleasemod() // Free!

To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftracelocationrange(); 2. Use ftracelocationrange() instead of lookuprec() in ftracelocation(); 3. Call synchronizercu() before freeing any ftrace pages both in ftraceprocesslocs()/ftracereleasemod()/ftracefree_mem().(CVE-2024-38588)

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

md: fix resync softlockup when bitmap size is less than array size

Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup:

kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdXresync:6976] CPU: 7 PID: 3588 Comm: mdXresync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:rawspinunlockirq+0x13/0x30 Call Trace: <TASK> mdbitmapstartsync+0x6b/0xf0 raid10syncrequest+0x25c/0x1b40 [raid10] mddosync+0x64b/0x1020 mdthread+0xa7/0x170 kthread+0xcf/0x100 retfromfork+0x30/0x50 retfromfork_asm+0x1a/0x30

And the detailed process is as follows:

mddosync j = mddev->resyncmin while (j < maxsectors) sectors = raid10syncrequest(mddev, j, &skipped) if (!mdbitmapstartsync(..., &syncblocks)) // mdbitmapstartsync set syncblocks to 0 return syncblocks + sectorsskippe; // sectors = 0; j += sectors; // j never change

Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in mdbitmapgetcounter") return early from mdbitmapgetcounter(), without setting returned blocks.

Fix this problem by always set returned blocks from mdbitmapget_counter"(), as it used to be.

Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.(CVE-2024-38598)

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

jffs2: prevent xattr node from overflowing the eraseblock

Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker.

Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as:

jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) doverifyxattrdatum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2getinodenodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2scaneraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead

This breaks the filesystem and can lead to KASAN crashes such as:

BUG: KASAN: slab-out-of-bounds in jffs2sumaddkvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0xc6/0x120 printreport+0xc4/0x620 ? _virtaddrvalid+0x308/0x5b0 kasanreport+0xc1/0xf0 ? jffs2sumaddkvec+0x125e/0x15d0 ? jffs2sumaddkvec+0x125e/0x15d0 jffs2sumaddkvec+0x125e/0x15d0 jffs2flashdirectwritev+0xa8/0xd0 jffs2flashwritev+0x9c9/0xef0 ? _x64syssetxattr+0xc4/0x160 ? dosyscall64+0x69/0x140 ? entrySYSCALL64after_hwframe+0x76/0x7e [...]

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-38599)

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

ax25: Fix reference count leak issues of ax25_dev

The ax25addrax25dev() and ax25devdevicedown() exist a reference count leak issue of the object "ax25dev".

Memory leak issue in ax25addrax25dev():

The reference count of the object "ax25dev" can be increased multiple times in ax25addr_ax25dev(). This will cause a memory leak.

Memory leak issues in ax25devdevice_down():

The reference count of ax25dev is set to 1 in ax25devdeviceup() and then increase the reference count when ax25dev is added to ax25devlist. As a result, the reference count of ax25dev is 2. But when the device is shutting down. The ax25devdevicedown() drops the reference count once or twice depending on if we goto unlockput or not, which will cause memory leak.

As for the issue of ax25addrax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25addrax25dev(). As for the issue of ax25devdevicedown(), increase the reference count of ax25dev once in ax25devdeviceup() and decrease the reference count of ax25dev after it is removed from the ax25devlist.(CVE-2024-38602)

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

block: refine the EOF check in blkdeviomapbegin

blkdeviomapbegin rounds down the offset to the logical block size before stashing it in iomap->offset and checking that it still is inside the inode size.

Check the i_size check to the raw pos value so that we don't try a zero size write if iter->pos is unaligned.(CVE-2024-38604)

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

drivers/virt/acrn: fix PFNMAP PTE checks in acrnvmram_map()

Patch series "mm: followpte() improvements and acrn followpte() fixes".

Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks.

Patch #2+#3 improve followpte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VMPAT that ends up using follow_pte().

This patch (of 3):

We currently miss handling various cases, resulting in a dangerous followpte() (previously followpfn()) usage.

(1) We're not checking PTE write permissions.

Maybe we should simply always require ptewrite() like we do for pinuserpagesfast(FOLLWRITE)? Hard to tell, so let's check for ACRNMEMACCESSWRITE for now.

(2) We're not rejecting refcounted pages.

As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them.

(3) We are only looking at the first PTE of a bigger range.

We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing.(CVE-2024-38610)

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

drm/msm/dpu: Add callback function pointer check before its call

In dpucoreirqcallbackhandler() callback function pointer is compared to NULL, but then callback function is unconditionally called by this pointer. Fix this bug by adding conditional return.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Patchwork: https://patchwork.freedesktop.org/patch/588237/(CVE-2024-38622)

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

fs/ntfs3: Use variable length array instead of fixed size

Should fix smatch warning: ntfssetlabel() error: _builtinmemcpy() 'uni->name' too small (20 vs 256)(CVE-2024-38623)

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

fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow

For example, in the expression: vbo = 2 * vbo + skip(CVE-2024-38624)

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

fs/ntfs3: Check 'folio' pointer for NULL

It can be NULL if bmap is called.(CVE-2024-38625)

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

usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.

Hang on to the control IDs instead of pointers since those are correctly handled with locks.(CVE-2024-38628)

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

dmaengine: idxd: Avoid unnecessary destruction of file_ida

fileida is allocated during cdev open and is freed accordingly during cdev release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an already empty fileida when the WQ cdev is removed.

Worse, idafree() in cdev release may happen after destruction of fileida per WQ cdev. This can lead to accessing an id in file_ida after it has been destroyed, resulting in a kernel panic.

Remove idadestroy(&fileida) to address these issues.(CVE-2024-38629)

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

watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger

When the cpu5wdt module is removing, the origin code uses deltimer() to de-activate the timer. If the timer handler is running, deltimer() could not stop it and will return directly. If the port region is released by releaseregion() and then the timer handler cpu5wdttrigger() calls outb() to write into the region that is released, the use-after-free bug will happen.

Change deltimer() to timershutdown_sync() in order that the timer handler could be finished before the port region is released.(CVE-2024-38630)

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

serial: max3100: Lock port->lock when calling uarthandlects_change()

uarthandlects_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:

WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serialcore.c:3491 uarthandlectschange+0xa6/0xb0 ... Workqueue: max3100-0 max3100work [max3100] RIP: 0010:uarthandlectschange+0xa6/0xb0 ... max3100handlerx+0xc5/0x110 [max3100] max3100work+0x12a/0x340 max3100

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

greybus: lights: check return of getchannelfrom_mode

If channel for the given node is not found we return null from getchannelfrom_mode. Make sure we validate the return pointer before using it in two of the missing places.

This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE.

[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru(CVE-2024-38637)

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

bpf: Allow delete from sockmap/sockhash only if update is allowed

We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash.

We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map.

From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types.(CVE-2024-38662)

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

drm: zynqmp_dpsub: Always register bridge

We must always register the DRM bridge, since zynqmpdphpdworkfunc calls drmbridgehpdnotify, which in turn expects hpdmutex to be initialized. We do this before zynqmpdpsubdrminit since that calls drmbridge_attach. This fixes the following lockdep warning:

[ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUGLOCKSWARNON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 _mutexlock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmpdphpdworkfunc [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : _mutexlock+0x4bc/0x550 [ 19.273364] lr : _mutexlock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] _mutexlock+0x4bc/0x550 [ 19.363032] mutexlocknested+0x24/0x30 [ 19.367187] drmbridgehpdnotify+0x2c/0x6c [ 19.371698] zynqmpdphpdworkfunc+0x44/0x54 [ 19.376364] processonework+0x3ac/0x988 [ 19.380660] workerthread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] retfromfork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finishtaskswitch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] _schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcuinvokecallbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcuinvokecallbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]---

(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)(CVE-2024-38664)

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

dma-buf/sw-sync: don't enable IRQ from syncprintobj()

Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spinunlockirqrestore() with spinunlockirq() for both syncdebugfsshow() and syncprintobj() despite syncprintobj() is called from syncdebugfsshow(), lockdep complains inconsistent lock state warning.

Use plain spin{lock,unlock}() for syncprintobj(), for syncdebugfsshow() is already using spin{lock,unlock}_irq().(CVE-2024-38780)

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

bonding: fix oops during rmmod

"rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding: remove redundant NULL check in debugfs function"). Here are the relevant functions being called:

bondingexit() bonddestroydebugfs() debugfsremoverecursive(bondingdebugroot); bondingdebugroot = NULL; <--------- SET TO NULL HERE bondnetlinkfini() rtnllinkunregister() _rtnllinkunregister() unregisternetdevicemanynotify() bonduninit() bonddebugunregister() (commit removed check for bondingdebugroot == NULL) debugfsremove() simplerecursiveremoval() downwrite() -> OOPS

However, reverting the bad commit does not solve the problem completely because the original code contains a race that could cause the same oops, although it was much less likely to be triggered unintentionally:

CPU1 rmmod bonding bondingexit() bonddestroydebugfs() debugfsremoverecursive(bondingdebug_root);

CPU2 echo -bond0 > /sys/class/net/bondingmasters bonduninit() bonddebugunregister() if (!bondingdebugroot)

CPU1 bondingdebugroot = NULL;

So do NOT revert the bad commit (since the removed checks were racy anyway), and instead change the order of actions taken during module removal. The same oops can also happen if there is an error during module init, so apply the same fix there.(CVE-2024-39296)

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

net/9p: fix uninit-value in p9clientrpc()

Syzbot with the help of KMSAN reported the following error:

BUG: KMSAN: uninit-value in trace9pclientres include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9clientrpc+0x1314/0x1340 net/9p/client.c:754 trace9pclientres include/trace/events/9p.h:146 [inline] p9clientrpc+0x1314/0x1340 net/9p/client.c:754 p9clientcreate+0x1551/0x1ff0 net/9p/client.c:1031 v9fssessioninit+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fsmount+0xe2/0x12b0 fs/9p/vfssuper.c:122 legacygettree+0x114/0x290 fs/fscontext.c:662 vfsgettree+0xa7/0x570 fs/super.c:1797 donewmount+0x71f/0x15e0 fs/namespace.c:3352 pathmount+0x742/0x1f20 fs/namespace.c:3679 domount fs/namespace.c:3692 [inline] _dosysmount fs/namespace.c:3898 [inline] _sesysmount+0x725/0x810 fs/namespace.c:3875 _x64sysmount+0xe4/0x150 fs/namespace.c:3875 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: allocpages+0x9d6/0xe70 mm/pagealloc.c:4598 _allocpagesnode include/linux/gfp.h:238 [inline] allocpagesnode include/linux/gfp.h:261 [inline] allocslabpage mm/slub.c:2175 [inline] allocateslab mm/slub.c:2338 [inline] newslab+0x2de/0x1400 mm/slub.c:2391 _slaballoc+0x1184/0x33d0 mm/slub.c:3525 _slaballoc mm/slub.c:3610 [inline] _slaballocnode mm/slub.c:3663 [inline] slaballocnode mm/slub.c:3835 [inline] kmemcachealloc+0x6d3/0xbe0 mm/slub.c:3852 p9tagalloc net/9p/client.c:278 [inline] p9clientpreparereq+0x20a/0x1770 net/9p/client.c:641 p9clientrpc+0x27e/0x1340 net/9p/client.c:688 p9clientcreate+0x1551/0x1ff0 net/9p/client.c:1031 v9fssessioninit+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fsmount+0xe2/0x12b0 fs/9p/vfssuper.c:122 legacygettree+0x114/0x290 fs/fscontext.c:662 vfsgettree+0xa7/0x570 fs/super.c:1797 donewmount+0x71f/0x15e0 fs/namespace.c:3352 pathmount+0x742/0x1f20 fs/namespace.c:3679 domount fs/namespace.c:3692 [inline] _dosysmount fs/namespace.c:3898 [inline] _sesysmount+0x725/0x810 fs/namespace.c:3875 _x64sysmount+0xe4/0x150 fs/namespace.c:3875 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

If p9checkerrors() fails early in p9clientrpc(), req->rc.tag will not be properly initialized. However, trace9pclientres() ends up trying to print it out anyway before p9client_rpc() finishes.

Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage.(CVE-2024-39301)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)

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

iouring: check for non-NULL file pointer in iofilecanpoll()

In earlier kernels, it was possible to trigger a NULL pointer dereference off the forced async preparation path, if no file had been assigned. The trace leading to that looks as follows:

BUG: kernel NULL pointer dereference, address: 00000000000000b0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022 RIP: 0010:iobufferselect+0xc3/0x210 Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246 RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040 RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700 RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020 R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8 R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000 FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0 Call Trace: <TASK> ? _die+0x1f/0x60 ? pagefaultoops+0x14d/0x420 ? douseraddrfault+0x61/0x6a0 ? excpagefault+0x6c/0x150 ? asmexcpagefault+0x22/0x30 ? iobufferselect+0xc3/0x210 _ioimportiovec+0xb5/0x120 ioreadvprepasync+0x36/0x70 ioqueuesqefallback+0x20/0x260 iosubmitsqes+0x314/0x630 _dosysiouringenter+0x339/0xbc0 ? _dosysiouringregister+0x11b/0xc50 ? vmmmappgoff+0xce/0x160 dosyscall64+0x5f/0x180 entrySYSCALL64afterhwframe+0x46/0x4e RIP: 0033:0x55e0a110a67e Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6

because the request is marked forced ASYNC and has a bad file fd, and hence takes the forced async prep path.

Current kernels with the request async prep cleaned up can no longer hit this issue, but for ease of backporting, let's add this safety check in here too as it really doesn't hurt. For both cases, this will inevitably end with a CQE posted with -EBADF.(CVE-2024-39371)

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

clk: bcm: rpi: Assign ->num before accessing ->hws

Commit f316cdff8d67 ("clk: Annotate struct clkhwonecelldata with _countedby") annotated the hws member of 'struct clkhwonecelldata' with _countedby, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the _countedby member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in raspberrypidiscoverclocks() due to ->num being assigned after ->hws has been accessed:

UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 index 3 is out of range for type 'struct clkhw *[] _countedby(num)' (aka 'struct clkhw *[]')

Move the ->num initialization to before the first access of ->hws, which clears up the warning.(CVE-2024-39461)

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

thermal/drivers/qcom/lmh: Check for SCM availability at probe

Up until now, the necessary scm availability check has not been performed, leading to possible null pointer dereferences (which did happen for me on RB1).

Fix that.(CVE-2024-39466)

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

f2fs: fix to do sanity check on ixattrnid in sanitycheckinode()

syzbot reports a kernel bug as below:

F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4

BUG: KASAN: slab-out-of-bounds in f2fstestbit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in currentnataddr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fsgetnode_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076

CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 f2fstestbit fs/f2fs/f2fs.h:2933 [inline] currentnataddr fs/f2fs/node.h:213 [inline] f2fsgetnodeinfo+0xece/0x1200 fs/f2fs/node.c:600 f2fsxattrfiemap fs/f2fs/data.c:1848 [inline] f2fsfiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctlfiemap fs/ioctl.c:220 [inline] dovfsioctl+0x1c07/0x2e50 fs/ioctl.c:838 _dosysioctl fs/ioctl.c:902 [inline] _sesysioctl+0x81/0x170 fs/ioctl.c:890 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

The root cause is we missed to do sanity check on ixattrnid during f2fsiget(), so that in fiemap() path, currentnataddr() will access natbitmap w/ offset from invalid ixattrnid, result in triggering kasan bug report, fix it.(CVE-2024-39467)

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

smb: client: fix deadlock in smb2findsmb_tcon()

Unlock cifstcpseslock before calling cifsputsmbses() to avoid such deadlock.(CVE-2024-39468)

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

eventfs: Fix a possible null pointer dereference in eventfsfindevents()

In function eventfsfindevents,there is a potential null pointer that may be caused by calling updateeventsattr which will perform some operations on the members of the ei struct when ei is NULL.

Hence,When ei->is_freed is set,return NULL directly.(CVE-2024-39470)