OESA-2024-2154

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

jfs: fix null ptr deref in dtInsertEntry

[syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfsdtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpyto_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time.

[Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL.(CVE-2024-44939)

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

usb: gadget: core: Check for unset descriptor

Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case.

This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found.

No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets.(CVE-2024-44960)

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

net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink

When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5wqll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list.

Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again.(CVE-2024-44970)

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

ipv6: prevent possible UAF in ip6_xmit()

If skbexpandhead() returns NULL, skb has been freed and the associated dst/idev could also have been freed.

We must use rcureadlock() to prevent a possible UAF.(CVE-2024-44985)

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

ipv6: fix possible UAF in ip6finishoutput2()

If skbexpandhead() returns NULL, skb has been freed and associated dst/idev could also have been freed.

We need to hold rcureadlock() to make sure the dst and associated idev are alive.(CVE-2024-44986)

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

ipv6: prevent UAF in ip6sendskb()

syzbot reported an UAF in ip6sendskb() [1]

After ip6localout() has returned, we no longer can safely dereference rt, unless we hold rcureadlock().

A similar issue has been fixed in commit a688caa34beb ("ipv6: take rcu lock in rawv6sendhdrinc()")

Another potential issue in ip6finishoutput2() is handled in a separate patch.

[1] BUG: KASAN: slab-use-after-free in ip6sendskb+0x18d/0x230 net/ipv6/ip6_output.c:1964 Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530

CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 ip6sendskb+0x18d/0x230 net/ipv6/ip6output.c:1964 rawv6pushpendingframes+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x1a6/0x270 net/socket.c:745 sockwriteiter+0x2dd/0x400 net/socket.c:1160 doiterreadvwritev+0x60a/0x890 vfswritev+0x37c/0xbb0 fs/readwrite.c:971 dowritev+0x1b1/0x350 fs/readwrite.c:1018 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f936bf79e79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79 RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 </TASK>

Allocated by task 6530: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 unpoisonslabobject mm/kasan/common.c:312 [inline] kasanslaballoc+0x66/0x80 mm/kasan/common.c:338 kasanslaballoc include/linux/kasan.h:201 [inline] slabpostallochook mm/slub.c:3988 [inline] slaballocnode mm/slub.c:4037 [inline] kmemcacheallocnoprof+0x135/0x2a0 mm/slub.c:4044 dstalloc+0x12b/0x190 net/core/dst.c:89 ip6blackholeroute+0x59/0x340 net/ipv6/route.c:2670 makeblackhole net/xfrm/xfrmpolicy.c:3120 [inline] xfrmlookuproute+0xd1/0x1c0 net/xfrm/xfrmpolicy.c:3313 ip6dstlookupflow+0x13e/0x180 net/ipv6/ip6output.c:1257 rawv6sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x1a6/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2597 _syssendmsg net/socket.c:2651 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2680 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 45: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:579 poisonslabobject+0xe0/0x150 mm/kasan/common.c:240 _kasanslabfree+0x37/0x60 mm/kasan/common.c:256 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2252 [inline] slabfree mm/slub.c:4473 [inline] kmemcachefree+0x145/0x350 mm/slub.c:4548 dstdestroy+0x2ac/0x460 net/core/dst.c:124 rcudobatch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree. ---truncated---(CVE-2024-44987)

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

net: dsa: mv88e6xxx: Fix out-of-bound access

If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSAMAXPORTS (the size of mv88e6xxx_chip.ports[] array).(CVE-2024-44988)

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

bpf: Fix a kernel verifier crash in stacksafe()

Daniel Hodges reported a kernel verifier crash when playing with sched-ext. Further investigation shows that the crash is due to invalid memory access in stacksafe(). More specifically, it is the following code:

if (exact != NOT_EXACT &&
    old->stack[spi].slot_type[i % BPF_REG_SIZE] !=
    cur->stack[spi].slot_type[i % BPF_REG_SIZE])
        return false;

The 'i' iterates old->allocatedstack. If cur->allocatedstack < old->allocated_stack the out-of-bound access will happen.

To fix the issue add 'i >= cur->allocatedstack' check such that if the condition is true, stacksafe() should fail. Otherwise, cur->stack[spi].slottype[i % BPFREGSIZE] memory access is legal.(CVE-2024-45020)