OESA-2024-1863

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

rtnetlink: Correct nested IFLAVFVLAN_LIST attribute validation

Each attribute inside a nested IFLAVFVLANLIST is assumed to be a struct iflavfvlaninfo so the size of such attribute needs to be at least of sizeof(struct iflavfvlaninfo) which is 14 bytes. The current size validation in dosetvfinfo is against NLAHDRLEN (4 bytes) which is less than sizeof(struct iflavfvlaninfo) so this validation is not enough and a too small attribute might be cast to a struct iflavfvlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)

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

nullblk: fix null-ptr-dereference while configuring 'power' and 'submitqueues'

Writing 'power' and 'submit_queues' concurrently will trigger kernel panic:

Test script:

modprobe nullblk nrdevices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submitqueues; echo 4 > submitqueues; done & while true; do echo 1 > power; echo 0 > power; done

Test result:

BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:_lockacquire+0x41d/0x28f0 Call Trace: <TASK> lockacquire+0x121/0x450 downwrite+0x5f/0x1d0 simplerecursiveremoval+0x12f/0x5c0 blkmqdebugfsunregisterhctxs+0x7c/0x100 blkmqupdatenrhwqueues+0x4a3/0x720 nullbupdatenrhwqueues+0x71/0xf0 [nullblk] nullbdevicesubmitqueuesstore+0x79/0xf0 [nullblk] configfswriteiter+0x119/0x1e0 vfswrite+0x326/0x730 ksys_write+0x74/0x150

This is because delgendisk() can concurrent with blkmqupdatenrhwqueues():

nullbdevicepowerstore nullbapplysubmitqueues nulldeldev delgendisk nullbupdatenrhwqueues if (!dev->nullb) // still set while gendisk is deleted return 0 blkmqupdatenrhwqueues dev->nullb = NULL

Fix this problem by resuing the global mutex to protect nullbdevicepowerstore() and nullbupdatenrhw_queues() from configfs.(CVE-2024-36478)

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

tracing/probes: fix error check in parsebtffield()

btffindstructmember() might return NULL or an error via the ERRPTR() macro. However, its caller in parsebtffield() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack.(CVE-2024-36481)

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

scsi: lpfc: Release hbalock before calling lpfcworkerwake_up()

lpfcworkerwakeup() calls the lpfcworkdone() routine, which takes the hbalock. Thus, lpfcworkerwakeup() should not be called while holding the hbalock to avoid potential deadlock.(CVE-2024-36924)

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

net: core: reject skbcopy(expand) for fraglist GSO skbs

SKBGSOFRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skbcopy or skbcopyexpand, in order to prevent a crash on a potential later call to skbgso_segment.(CVE-2024-36929)

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

s390/cio: Ensure the copied buf is NUL terminated

Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from userspace to that buffer. Later, we use scanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using scanf. Fix this issue by using memdupusernul instead.(CVE-2024-36931)

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

drm/amdkfd: range check cp bad op exception interrupts

Due to a CP interrupt bug, bad packet garbage exception codes are raised. Do a range check so that the debugger and runtime do not receive garbage codes. Update the user api to guard exception code type checking as well.(CVE-2024-36951)

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

blk-cgroup: fix list corruption from reorder of WRITE ->lqueued

_blkcgrstatflush() can be run anytime, especially when blkcgroupbiostart is being executed.

If WRITE of ->lqueued is re-ordered with READ of 'bisc->lnode.next' in the loop of _blkcgrstatflush(), next_bisc can be assigned with one stat instance being added in blkcgroupbiostart(), then the local list in _blkcgrstat_flush() could be corrupted.

Fix the issue by adding one barrier.(CVE-2024-38384)

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

net: openvswitch: fix overwriting ct original tuple for ICMPv6

OVSPACKETCMDEXECUTE has 3 main attributes: - OVSPACKETATTRKEY - Packet metadata in a netlink format. - OVSPACKETATTRPACKET - Binary packet content. - OVSPACKETATTRACTIONS - Actions to execute on the packet.

OVSPACKETATTRKEY is parsed first to populate swflow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers.

Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.

It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ctorig' that holds the original tuple conntrack metadata parsed from the OVSPACKETATTRKEY.

ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten.

The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace.

ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.

Initializing the whole thing before parsing is needed because ND packet may not contain all the options.

The issue only affects the OVSPACKETCMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.(CVE-2024-38558)

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

gfs2: Fix potential glock use-after-free on unmount

When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.

To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sddeadglocks list, release the lockspace, and only then free those glocks.

As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.(CVE-2024-38570)

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

drm/amdgpu/mes: fix use-after-free issue

Delete fence fallback timer to fix the ramdom use-after-free issue.

v2: move to amdgpu_mes.c(CVE-2024-38581)

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:

r8169: Fix possible ring buffer corruption on fragmented Tx packets.

An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dmaunmapsingle() with a null address.

This was caused by rtl8169startxmit() not noticing changes to nrfrags which may occur when small packets are padded (to work around hardware quirks) in rtl8169tsocsumv2().

To fix this, postpone inspecting nr_frags until after any padding has been applied.(CVE-2024-38586)

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

openrisc: traps: Don't send signals to kernel mode threads

OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error.

This patch adds conditions to die if the kernel receives these exceptions in kernel mode code.(CVE-2024-38614)

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

Bluetooth: HCI: Remove HCI_AMP support

Since BTHS has been remove HCIAMP controllers no longer has any use so remove it along with the capability of creating AMP controllers.

Since we no longer need to differentiate between AMP and Primary controllers, as only HCIPRIMARY is left, this also remove hdev->devtype altogether.(CVE-2024-38620)

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

vfio/pci: fix potential memory leak in vfiointxenable()

If vfioirqctx_alloc() failed will lead to 'name' memory leak.(CVE-2024-38632)

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

s390/ap: Fix crash in AP internal function modify_bitmap()

A system crash like this

Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (apparsebitmapstr+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] apparsebitmapstr+0x10e/0x1f8 ([<0000014b75e7b5dc>] apparsebitmapstr+0xe4/0x1f8) [<0000014b75e7b758>] apmaskstore+0x68/0x140 [<0000014b75679196>] kernfsfopwriteiter+0x14e/0x1e8 [<0000014b75598524>] vfswrite+0x1b4/0x448 [<0000014b7559894c>] ksyswrite+0x74/0x100 [<0000014b7618a440>] _dosyscall+0x268/0x328 [<0000014b761a3558>] systemcall+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] apparsebitmapstr+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: paniconoops

occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.

The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.(CVE-2024-38661)

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

clk: bcm: dvp: 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 clkdvpprobe() due to ->num being assigned after ->hws has been accessed:

UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2 index 0 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-39462)

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

media: v4l: async: Fix notifier list entry init

struct v4l2asyncnotifier has several listhead members, but only waitinglist and donelist are initialized. notifierentry was kept 'zeroed' leading to an uninitialized listhead. This results in a NULL-pointer dereference if csi2asyncregister() fails, e.g. node for remote endpoint is disabled, and returns -ENOTCONN. The following calls to v4l2asyncnfunregister() results in a NULL pointer dereference. Add the missing list head initializer.(CVE-2024-39464)

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

crypto: starfive - Do not free stack buffer

RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations.(CVE-2024-39478)

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

drm/i915/hwmon: Get rid of devm

When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below):

Call Trace: releasenodes+0x11/0x70 devresreleasegroup+0xb2/0x110 componentunbindall+0x8d/0xa0 componentdel+0xa5/0x140 intelpxpteecomponentfini+0x29/0x40 [i915] intelpxpfini+0x33/0x80 [i915] i915driverremove+0x4c/0x120 [i915] i915pciremove+0x19/0x30 [i915] pcideviceremove+0x32/0xa0 devicereleasedriverinternal+0x19c/0x200 unbindstore+0x9c/0xb0

and

Call Trace: releasenodes+0x11/0x70 devresreleaseall+0x8a/0xc0 deviceunbindcleanup+0x9/0x70 devicereleasedriverinternal+0x1c1/0x200 unbind_store+0x9c/0xb0

This means that in i915, if use devm, we cannot gurantee that hwmon will always be released before drvdata. Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't.

The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind.

v2: Change commit message and other minor code changes v3: Cleanup from i915hwmonregister on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetchandzero (Jani) v5: Restore previous logic for ddatgt->hwmondev error return (Andi)(CVE-2024-39479)

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

kdb: Fix buffer overflow during tab-complete

Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer.

Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.(CVE-2024-39480)

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

bonding: Fix out-of-bounds read in bondoptionarpiptargets_set()

In function bondoptionarpiptargets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read.

BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x150 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:364 [inline] printreport+0xc1/0x5e0 mm/kasan/report.c:475 kasanreport+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 _fortifystrlen include/linux/fortify-string.h:210 [inline] in4pton+0xa3/0x3f0 net/core/utils.c:130 bondoptionarpiptargetsset+0xc2/0x910 drivers/net/bonding/bondoptions.c:1201 _bondoptset+0x2a4/0x1030 drivers/net/bonding/bondoptions.c:767 _bondoptsetnotify+0x48/0x150 drivers/net/bonding/bondoptions.c:792 bondopttrysetrtnl+0xda/0x160 drivers/net/bonding/bondoptions.c:817 bondingsysfsstoreoption+0xa1/0x120 drivers/net/bonding/bondsysfs.c:156 devattrstore+0x54/0x80 drivers/base/core.c:2366 sysfskfwrite+0x114/0x170 fs/sysfs/file.c:136 kernfsfopwriteiter+0x337/0x500 fs/kernfs/file.c:334 callwriteiter include/linux/fs.h:2020 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x96a/0xd80 fs/readwrite.c:584 ksyswrite+0x122/0x250 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x40/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b ---[ end trace ]---

Fix it by adding a check of string length before using it.(CVE-2024-39487)

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

arm64: asm-bug: Add .align 2 to the end of _BUGENTRY

When CONFIGDEBUGBUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly.

The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays.

When CONFIGDEBUGBUGVERPOSE=y, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    signed int      file_disp;  // 4 bytes
    unsigned short  line;       // 2 bytes
    unsigned short  flags;      // 2 bytes
}

... with 12 bytes total, requiring 4-byte alignment.

When CONFIGDEBUGBUGVERBOSE=n, the layout of a bug_entry is:

struct bug_entry {
    signed int      bug_addr_disp;  // 4 bytes
    unsigned short  flags;      // 2 bytes
    < implicit padding >      // 2 bytes
}

... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment.

When we create a bugentry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIGDEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes.

For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries:

for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
    if (bugaddr == bug_addr(bug))
        return bug;

However for modules, modulebugfinalize() depends on the trailing bytes when calculating the number of entries:

mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);

... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry:

sechdrs[i].sh_size == 6
sizeof(struct bug_entry) == 8;

sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;

Consequently modulefindbug() will miss the last bug_entry when it does:

for (i = 0; i < mod->num_bugs; ++i, ++bug)
    if (bugaddr == bug_addr(bug))
        goto out;

... which can lead to a kenrel panic due to an unhandled bug.

This can be demonstrated with the following module:

static int __init buginit(void)
{
    WARN(1, "hello\n");
    return 0;
}

static void __exit bugexit(void)
{
}

module_init(buginit);
module_exit(bugexit);
MODULE_LICENSE("GPL");

... which will trigger a kernel panic when loaded:

------------[ cut here ]------------
hello
Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: hello(O+)
CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8
Hardware name: linux,dummy-virt (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : buginit+0x18/0x1000 [hello]
lr : buginit+0x18/0x1000 [hello]
sp : ffff800080533ae0
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
Call trace:
 buginit+0x18/0x1000 [hello]
 do_one_initcall+0x80/0x1c8
 do_init_module+0x60/0x218
 load_module+0x1ba4/0x1d70
 __do_sys_init_module+0x198/0x1d0
 __arm64_sys_init_module+0x1c/0x28
 invoke_syscall+0x48/0x114
 el0_svc

---truncated---(CVE-2024-39488)

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

ipv6: sr: fix memleak in seg6hmacinit_algo

seg6hmacinit_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms.

Update seg6hmacexit to only free the memory when allocated, so we can reuse the code directly.(CVE-2024-39489)

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

sockmap: avoid race between sockmapclose and skpsock_put

skpsockget will return NULL if the refcount of psock has gone to 0, which will happen when the last call of skpsockput is done. However, skpsockdrop may not have finished yet, so the close callback will still point to sockmapclose despite psock being NULL.

This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it.

That will trigger the WARNONONCE:

------------[ cut here ]------------ WARNING: CPU: 1 PID: 7220 at net/core/sockmap.c:1701 sockmapclose+0x2a2/0x2d0 net/core/sockmap.c:1701 Modules linked in: CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:sockmapclose+0x2a2/0x2d0 net/core/sockmap.c:1701 Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840 R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Call Trace: <TASK> unixrelease+0x87/0xc0 net/unix/afunix.c:1048 _sockrelease net/socket.c:659 [inline] sockclose+0xbe/0x240 net/socket.c:1421 _fput+0x42b/0x8a0 fs/filetable.c:422 _dosysclose fs/open.c:1556 [inline] _sesysclose fs/open.c:1541 [inline] _x64sysclose+0x7f/0x110 fs/open.c:1541 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIGRAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>

Use skpsock, which will only check that the pointer is not been set to NULL yet, which should only happen after the callbacks are restored. If, then, a reference can still be gotten, we may call skpsock_stop and cancel psock->work.

As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted.

After that change, the reproducer does not trigger the WARNONONCE anymore.(CVE-2024-39500)

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

ionic: fix use after netifnapidel()

When queues are started, netifnapiadd() and napienable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionicqcqenable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netifnapiadd(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netifnapidel() doesn't reset the .poll pointer to NULL. So, ionicqcqenable() calls napienable() for the queue, which was unregistered by netifnapidel().

Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4

Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ioniclifdeferredwork [ionic] RIP: 0010:napienable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x33/0x90 ? dotrap+0xd9/0x100 ? napienable+0x3b/0x40 ? doerrortrap+0x83/0xb0 ? napienable+0x3b/0x40 ? napienable+0x3b/0x40 ? excinvalidop+0x4e/0x70 ? napienable+0x3b/0x40 ? asmexcinvalidop+0x16/0x20 ? napienable+0x3b/0x40 ionicqcqenable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionicstartqueues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ioniclinkstatuscheck+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ioniclifdeferredwork+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] processonework+0x145/0x360 workerthread+0x2bb/0x3d0 ? _pfxworkerthread+0x10/0x10 kthread+0xcc/0x100 ? _pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30(CVE-2024-39502)

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

ipv6: fix possible race in _fib6droppcpufrom()

syzbot found a race in _fib6droppcpufrom() [1]

If compiler reads more than once (*ppcpurt), second read could read NULL, if another cpu clears the value in rt6getpcpuroute().

Add a READ_ONCE() to prevent this race.

Also add rcureadlock()/rcureadunlock() because we rely on RCU protection while dereferencing pcpu_rt.

[1]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanupnet RIP: 0010:fib6droppcpufrom.part.0+0x10a/0x370 net/ipv6/ip6fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _fib6droppcpufrom net/ipv6/ip6fib.c:966 [inline] fib6droppcpufrom net/ipv6/ip6fib.c:1027 [inline] fib6purgert+0x7f2/0x9f0 net/ipv6/ip6fib.c:1038 fib6delroute net/ipv6/ip6fib.c:1998 [inline] fib6del+0xa70/0x17b0 net/ipv6/ip6fib.c:2043 fib6cleannode+0x426/0x5b0 net/ipv6/ip6fib.c:2205 fib6walkcontinue+0x44f/0x8d0 net/ipv6/ip6fib.c:2127 fib6walk+0x182/0x370 net/ipv6/ip6fib.c:2175 fib6cleantree+0xd7/0x120 net/ipv6/ip6fib.c:2255 _fib6cleanall+0x100/0x2d0 net/ipv6/ip6fib.c:2271 rt6syncdowndev net/ipv6/route.c:4906 [inline] rt6disableip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconfifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconfnotify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifiercallchain+0xb9/0x410 kernel/notifier.c:93 callnetdevicenotifiersinfo+0xbe/0x140 net/core/dev.c:1992 callnetdevicenotifiersextack net/core/dev.c:2030 [inline] callnetdevicenotifiers net/core/dev.c:2044 [inline] devclosemany+0x333/0x6a0 net/core/dev.c:1585 unregisternetdevicemanynotify+0x46d/0x19f0 net/core/dev.c:11193 unregisternetdevicemany net/core/dev.c:11276 [inline] defaultdeviceexitbatch+0x85b/0xae0 net/core/dev.c:11759 opsexitlist+0x128/0x180 net/core/netnamespace.c:178 cleanupnet+0x5b7/0xbf0 net/core/netnamespace.c:640 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244(CVE-2024-40905)

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

mptcp: ensure snd_una is properly initialized on connect

This is strictly related to commit fb7a0d334894 ("mptcp: ensure sndnxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snduna is still left uninitialized.

Address the issue explicitly initializing snduna together with sndnxt and write_seq.(CVE-2024-40931)

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

HID: logitech-dj: Fix memory leak in logidjrecvswitchtodjmode()

Fix a memory leak on logidjrecvsendreport() error path.(CVE-2024-40934)

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

ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41hdaunbind()

The cs35l41hdaunbind() function clears the hdacomponent entry matching it's index and then dereferences the codec pointer held in the first element of the hdacomponent array, this is an issue when the device index was 0.

Instead use the codec pointer stashed in the cs35l41_hda structure as it will still be valid.(CVE-2024-40964)

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

f2fs: remove clear SBINLINECRYPT flag in defaultoptions

In f2fsremount, SBINLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable.

Thread A: Thread B:

-f2fsremount -f2fsfileopen or f2fsnewinode -defaultoptions <- clear SB_INLINECRYPT flag

                                      -fscrypt_select_encryption_impl

-parseoptions <- set SBINLINECRYPT again(CVE-2024-40971)

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

cpufreq: amd-pstate: fix memory leak on CPU EPP exit

The cpudata memory from kzalloc() in amdpstateeppcpuinit() is not freed in the analogous exit function, so fix that.

rjw: Subject and changelog edits