The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ASoC: SOF: Fix DSP oops stack dump output contents

Fix @buf arg given to hexdumpto_buffer() and stack address used in dump error output.(CVE-2021-47381)

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

ARM: 9170/1: fix panic when kasan and kprobe are enabled

arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic.

the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files.

for example, use kprobe insert on capcapable+20 after kasan enabled, the capcapable assembly code is as follows: <capcapable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <asanload4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulateldr assembly code after enabling kasan is as follows: c06f1384 <emulateldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <asanload4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulateldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <asanload4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <asanload4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <_asanload4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ......

when running in emulateldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, *pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at capcapable+0x14/0xb0 LR is at emulateldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (capcapable) from (kprobehandler+0x218/0x340) (kprobehandler) from (kprobetraphandler+0x24/0x48) (kprobetraphandler) from (doundefinstr+0x13c/0x364) (doundefinstr) from (undsvcfinish+0x0/0x30) (undsvcfinish) from (capcapable+0x18/0xb0) (capcapable) from (capvmenoughmemory+0x38/0x48) (capvmenoughmemory) from (securityvmenoughmemorymm+0x48/0x6c) (securityvmenoughmemorymm) from (copyprocess.constprop.5+0x16b4/0x25c8) (copyprocess.constprop.5) from (dofork+0xe8/0x55c) (dofork) from (SySclone+0x1c/0x24) (SySclone) from (systrace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)(CVE-2021-47618)

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

btrfs: fix use-after-free after failure to create a snapshot

At ioctl.c:createsnapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfscommit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot:

1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots;

2) We call btrfscommittransaction(), and it fails either at the first call to btrfsrundelayedrefs() or btrfsstartdirtyblock_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list;

3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free.

This issue could actually be detected by smatch, which produced the following warning:

fs/btrfs/ioctl.c:843 createsnapshot() warn: '&pendingsnapshot->list' not removed from list

So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfscommittransaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore.(CVE-2022-48733)

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

net/mlx5e: Avoid field-overflowing memcpy()

In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields.

Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler.

We were doing:

#define ETH_HLEN  14
#define VLAN_HLEN  4
...
#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
...
    struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
...
    struct mlx5_wqe_eth_seg  *eseg = &wqe->eth;
    struct mlx5_wqe_data_seg *dseg = wqe->data;
...
memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);

target is wqe->eth.inlinehdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlantci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes).

struct mlx5etxwqe { struct mlx5wqectrlseg ctrl; /* 0 16 */ struct mlx5wqeethseg eth; /* 16 16 / struct mlx5_wqe_data_seg data[]; / 32 0 */

    /* size: 32, cachelines: 1, members: 3 */
    /* last cacheline: 32 bytes */

};

struct mlx5wqeethseg { u8 swpouterl4offset; /* 0 1 / u8 swp_outer_l3_offset; / 1 1 / u8 swp_inner_l4_offset; / 2 1 / u8 swp_inner_l3_offset; / 3 1 / u8 cs_flags; / 4 1 / u8 swp_flags; / 5 1 / __be16 mss; / 6 2 / __be32 flow_table_metadata; / 8 4 / union { struct { __be16 sz; / 12 2 / u8 start[2]; / 14 2 / } inline_hdr; / 12 4 / struct { __be16 type; / 12 2 / __be16 vlan_tci; / 14 2 / } insert; / 12 4 / __be32 trailer; / 12 4 / }; / 12 4 */

    /* size: 16, cachelines: 1, members: 9 */
    /* last cacheline: 16 bytes */

};

struct mlx5wqedataseg { _be32 bytecount; /* 0 4 */ _be32 lkey; /* 4 4 / __be64 addr; / 8 8 */

    /* size: 16, cachelines: 1, members: 3 */
    /* last cacheline: 16 bytes */

};

So, split the memcpy() so the compiler can reason about the buffer sizes.

"pahole" shows no size nor member offset changes to struct mlx5etxwqe nor struct mlx5eumrwqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations).(CVE-2022-48744)

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

KVM: LAPIC: Also cancel preemption timer during SET_LAPIC

The below warning is splatting during guest reboot.

------------[ cut here ]------------ WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvmarchvcpuioctlrun+0x874/0x880 [kvm] CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G I 5.17.0-rc1+ #5 RIP: 0010:kvmarchvcpuioctlrun+0x874/0x880 [kvm] Call Trace: <TASK> kvmvcpuioctl+0x279/0x710 [kvm] _x64sysioctl+0x83/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64after_hwframe+0x44/0xae RIP: 0033:0x7fd39797350b

This can be triggered by not exposing tsc-deadline mode and doing a reboot in the guest. The lapicshutdown() function which is called in sysreboot path will not disarm the flying timer, it just masks LVTT. lapicshutdown() clears APIC state w/ LVTMASKED and timer-mode bit is 0, this can trigger timer-mode switch between tsc-deadline and oneshot/periodic, which can result in preemption timer be cancelled in apicupdatelvtt(). However, We can't depend on this when not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption timer. Qemu will synchronise states around reset, let's cancel preemption timer under KVMSETLAPIC.(CVE-2022-48765)

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:

Bluetooth: btusb: Add date->evt_skb is NULL check

fix crash because of null pointers

[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 6104.969667] #PF: supervisor read access in kernel mode [ 6104.969668] #PF: errorcode(0x0000) - not-present page [ 6104.969670] PGD 0 P4D 0 [ 6104.969673] Oops: 0000 [#1] SMP NOPTI [ 6104.969684] RIP: 0010:btusbmtkhciwmtsync+0x144/0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006 [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] PKRU: 55555554 [ 6104.969702] Call Trace: [ 6104.969708] btusbmtkshutdown+0x44/0x80 [btusb] [ 6104.969732] hcidevdoclose+0x470/0x5c0 [bluetooth] [ 6104.969748] hcirfkillsetblock+0x56/0xa0 [bluetooth] [ 6104.969753] rfkillsetblock+0x92/0x160 [ 6104.969755] rfkillfopwrite+0x136/0x1e0 [ 6104.969759] _vfswrite+0x18/0x40 [ 6104.969761] vfswrite+0xdf/0x1c0 [ 6104.969763] ksyswrite+0xb1/0xe0 [ 6104.969765] _x64syswrite+0x1a/0x20 [ 6104.969769] dosyscall64+0x51/0x180 [ 6104.969771] entrySYSCALL64afterhwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017 [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0(CVE-2023-52833)

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:

of: dynamic: Synchronize ofchangesetdestroy() with the devlink removals

In the following sequence: 1) ofplatformdepopulate() 2) ofoverlayremove()

During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but _ofchangesetentrydestroy() can raise warnings related to missing ofnodeput(): ERROR: memory leak, expected refcount 1 instead of 2 ...

Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached ofnode) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, ofnode_put() will be called but wrongly too late from the workqueue job.

In order to be sure that any ongoing devlink removals are done before the ofnode destruction, synchronize the ofchangeset_destroy() with the devlink removals.(CVE-2024-35879)

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

net/sched: act_skbmod: prevent kernel-infoleak

syzbot found that tcfskbmoddump() was copying four bytes from kernel stack to user space [1].

The issue here is that 'struct tc_skbmod' has a four bytes hole.

We need to clear the structure before filling fields.

[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] simplecopytoiter net/core/datagram.c:532 [inline] _skbdatagramiter+0x185/0x1000 net/core/datagram.c:420 skbcopydatagramiter+0x5c/0x200 net/core/datagram.c:546 skbcopydatagrammsg include/linux/skbuff.h:4050 [inline] netlinkrecvmsg+0x432/0x1610 net/netlink/afnetlink.c:1962 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x2c4/0x340 net/socket.c:1068 _sysrecvfrom+0x35a/0x5f0 net/socket.c:2242 _dosysrecvfrom net/socket.c:2260 [inline] _sesysrecvfrom net/socket.c:2256 [inline] _x64sysrecvfrom+0x126/0x1d0 net/socket.c:2256 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was stored to memory at: pskbexpandhead+0x30f/0x19d0 net/core/skbuff.c:2253 netlinktrim+0x2c2/0x330 net/netlink/afnetlink.c:1317 netlinkunicast+0x9f/0x1260 net/netlink/afnetlink.c:1351 nlmsgunicast include/net/netlink.h:1144 [inline] nlmsgnotify+0x21d/0x2f0 net/netlink/afnetlink.c:2610 rtnetlinksend+0x73/0x90 net/core/rtnetlink.c:741 rtnetlinkmaybesend include/linux/rtnetlink.h:17 [inline] tcfaddnotify net/sched/actapi.c:2048 [inline] tcfactionadd net/sched/actapi.c:2071 [inline] tcctlaction+0x146e/0x19d0 net/sched/actapi.c:2119 rtnetlinkrcvmsg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlinkrcvskb+0x375/0x650 net/netlink/afnetlink.c:2559 rtnetlinkrcv+0x34/0x40 net/core/rtnetlink.c:6613 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xf4c/0x1260 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10df/0x11f0 net/netlink/afnetlink.c:1905 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 dosyscall64+0xd5/0x1f0 entrySYSCALL64after_hwframe+0x6d/0x75

Uninit was stored to memory at: _nlaput lib/nlattr.c:1041 [inline] nlaput+0x1c6/0x230 lib/nlattr.c:1099 tcfskbmoddump+0x23f/0xc20 net/sched/actskbmod.c:256 tcfactiondumpold net/sched/actapi.c:1191 [inline] tcfactiondump1+0x85e/0x970 net/sched/actapi.c:1227 tcfactiondump+0x1fd/0x460 net/sched/actapi.c:1251 tcagetfill+0x519/0x7a0 net/sched/actapi.c:1628 tcfaddnotifymsg net/sched/actapi.c:2023 [inline] tcfaddnotify net/sched/actapi.c:2042 [inline] tcfactionadd net/sched/actapi.c:2071 [inline] tcctlaction+0x1365/0x19d0 net/sched/actapi.c:2119 rtnetlinkrcvmsg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlinkrcvskb+0x375/0x650 net/netlink/afnetli ---truncated---(CVE-2024-35893)

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

ipv6: fix race condition between ipv6getifaddr and ipv6deladdr

Although ipv6getifaddr walks inet6addrlst under the RCU lock, it still means hlistforeachentryrcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane.

In particular, the reference count can be zero. This can happen if ipv6deladdr is called in parallel. ipv6deladdr removes the entry from inet6addrlst (hlistdelinitrcu(&ifp->addrlst)) and drops all references (_in6ifaput(ifp) + in6ifa_put(ifp)). With bad enough timing, this can happen:

1. In ipv6getifaddr, hlistforeachentryrcu returns an entry.

2. Then, the whole ipv6deladdr is executed for the given entry. The reference count drops to zero and kfree_rcu is scheduled.

3. ipv6getifaddr continues and tries to increments the reference count (in6ifahold).

4. The rcu is unlocked and the entry is freed.

5. The freed entry is returned.

Prevent increasing of the reference count in such case. The name in6ifaholdsafe is chosen to mimic the existing fib6infoholdsafe.

[ 41.506330] refcountt: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcountwarnsaturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcountwarnsaturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? _warn+0x7b/0x120 [ 41.517535] ? refcountwarnsaturate+0xa5/0x130 [ 41.517923] ? reportbug+0x164/0x190 [ 41.518240] ? handlebug+0x3d/0x70 [ 41.518541] ? excinvalidop+0x17/0x70 [ 41.520972] ? asmexcinvalidop+0x1a/0x20 [ 41.521325] ? refcountwarnsaturate+0xa5/0x130 [ 41.521708] ipv6getifaddr+0xda/0xe0 [ 41.522035] inet6rtmgetaddr+0x342/0x3f0 [ 41.522376] ? _pfxinet6rtmgetaddr+0x10/0x10 [ 41.522758] rtnetlinkrcvmsg+0x334/0x3d0 [ 41.523102] ? netlinkunicast+0x30f/0x390 [ 41.523445] ? _pfxrtnetlinkrcvmsg+0x10/0x10 [ 41.523832] netlinkrcvskb+0x53/0x100 [ 41.524157] netlinkunicast+0x23b/0x390 [ 41.524484] netlinksendmsg+0x1f2/0x440 [ 41.524826] _syssendto+0x1d8/0x1f0 [ 41.525145] _x64syssendto+0x1f/0x30 [ 41.525467] dosyscall64+0xa5/0x1b0 [ 41.525794] entrySYSCALL64after_hwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated---(CVE-2024-35969)

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

riscv: Fix TASK_SIZE on 64-bit NOMMU

On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines.(CVE-2024-35988)

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

drm/arm/malidp: fix a possible null pointer dereference

In malidpmwconnectorreset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mwstate is checked before calling _drmatomichelperconnector_reset.(CVE-2024-36014)

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:

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:

nfc: nci: Fix uninit-value in ncirxwork

syzbot reported the following uninit-value access issue [1]

ncirxwork() parses received packet from ndev->rx_q. It should be validated header size, payload size and total packet size before processing the packet. If an invalid packet is detected, it should be silently discarded.(CVE-2024-38381)

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

media: atomisp: sshcss: Fix a null-pointer dereference in loadvideo_binaries

The allocation failure of mycs->yuvscalerbinary in loadvideobinaries() is followed with a dereference of mycs->yuvscalerbinary after the following call chain:

shcsspipeloadbinaries() |-> loadvideobinaries(mycs->yuvscalerbinary == NULL) | |-> shcsspipeunloadbinaries() |-> unloadvideobinaries()

In unloadvideobinaries(), it calls to iacssbinaryunload with argument &pipe->pipesettings.video.yuvscalerbinary[i], which refers to the same memory slot as mycs->yuvscalerbinary. Thus, a null-pointer dereference is triggered.(CVE-2024-38547)

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:

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:

nilfs2: fix use-after-free of timer for log writer thread

Patch series "nilfs2: fix log writer related issues".

This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log.

This patch (of 3):

A use-after-free issue has been reported regarding the timer sctimer on the nilfssc_info structure.

The problem is that even though it is used to wake up a sleeping log writer thread, sctimer is not shut down until the nilfssc_info structure is about to be freed, and is used regardless of the thread's lifetime.

Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.(CVE-2024-38583)

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

RDMA/hns: Modify the print level of CQE error

Too much print may lead to a panic in kernel. Change ibdeverr() to ibdeverr_ratelimited(), and change the printing level of cqe dump to debug level.(CVE-2024-38590)

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:

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:

drivers/perf: hisi: hns3: Actually use devmaddactionorreset()

pciallocirqvectors() allocates an irq vector. When devmadd_action() fails, the irq vector is not freed, which leads to a memory leak.

Replace the devmaddaction with devmaddactionorreset to ensure the irq vector can be destroyed when it fails.(CVE-2024-38603)

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

cpufreq: exit() callback is optional

The exit() callback is optional and shouldn't be called without checking a valid pointer first.

Also, we must clear freq_table pointer even if the exit() callback isn't present.(CVE-2024-38615)

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

media: stk1160: fix bounds checking in stk1160copyvideo()

The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true.

Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes.(CVE-2024-38621)

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: 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:

serial: max3100: Update uartdriverregistered on driver removal

The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses:

max3100 spi-PRP0001:01: max3100probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serialcoreregisterport+0xa0/0x840 ... max3100probe+0x1b6/0x280 [max3100] spiprobe+0x8d/0xb0

Update the actual state so next time UART driver will be registered again.

Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uartregisterdriver() call.(CVE-2024-38633)

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:

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:

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:

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)