OESA-2024-1682

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/amdgpu: handle the case of pcichanneliofrozen only in amdgpupci_resume

In current code, when a PCI error state pcichannelionormal is detectd, it will report PCIERSRESULTCANRECOVER status to PCI driver, and PCI driver will continue the execution of PCI resume callback reportresume by pciwalkbridge, and the callback will go into amdgpupciresume finally, where write lock is releasd unconditionally without acquiring such lock first. In this case, a deadlock will happen when other threads start to acquire the read lock.

To fix this, add a member in amdgpudevice strucutre to cache pcichannelstate, and only continue the execution in amdgpupciresume when it's pcichanneliofrozen.(CVE-2021-47421)

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

ptp: Fix possible memory leak in ptpclockregister()

I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] _kmalloctrackcaller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintfconst+0x60/0x190 [<00000000f323a5f7>] kobjectsetnamevargs+0x56/0x150 [<000000004e35abdd>] devsetname+0xc0/0x100 [<00000000f20cfe25>] ptpclockregister+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33probe.cold+0x8b6/0x1561 [ptp_idt82p33]

When posixclockregister() returns an error, the name allocated in devsetname() will be leaked, the putdevice() should be used to give up the device reference, then the name will be freed in kobjectcleanup() and other memory will be freed in ptpclockrelease().(CVE-2021-47455)

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

net: enetc: deny offload of tc-based TSN features on VF interfaces

TSN features on the ENETC (taprio, cbs, gate, police) are configured through a mix of command BD ring messages and port registers: enetcportrd(), enetcportwr().

Port registers are a region of the ENETC memory map which are only accessible from the PCIe Physical Function. They are not accessible from the Virtual Functions.

Moreover, attempting to access these registers crashes the kernel:

$ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriovnumvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fslenetcvf 0000:00:01.0: Adding to iommu group 15 fslenetcvf 0000:00:01.0: enabling device (0000 -> 0002) fslenetcvf 0000:00:01.0 eno0vf0: renamed from eth0 $ tc qdisc replace dev eno0vf0 root taprio numtc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2 Unable to handle kernel paging request at virtual address ffff800009551a08 Internal error: Oops: 96000007 [#1] PREEMPT SMP pc : enetcsetuptctaprio+0x170/0x47c lr : enetcsetuptctaprio+0x16c/0x47c Call trace: enetcsetuptctaprio+0x170/0x47c enetcsetuptc+0x38/0x2dc tapriochange+0x43c/0x970 taprioinit+0x188/0x1e0 qdisccreate+0x114/0x470 tcmodifyqdisc+0x1fc/0x6c0 rtnetlinkrcvmsg+0x12c/0x390

Split enetcsetuptc() into separate functions for the PF and for the VF drivers. Also remove enetc_qos.o from being included into enetc-vf.ko, since it serves absolutely no purpose there.(CVE-2022-48645)

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

drm/tegra: dsi: Add missing check for offinddevicebynode

Add check for the return value of offinddevicebynode() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)

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

NTB: fix possible name leak in ntbregisterdevice()

If deviceregister() fails in ntbregisterdevice(), the device name allocated by devsetname() should be freed. As per the comment in deviceregister(), callers should use putdevice() to give up the reference in the error path. So fix this by calling putdevice() in the error path so that the name can be freed in kobject_cleanup().

As a result of this, putdevice() in the error path of ntbregister_device() is removed and the actual error is returned.

mani: reworded commit message

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

SUNRPC: fix a memleak in gssimportv2_context

The ctx->mechused.data allocated by kmemdup is not freed in neither gssimportv2context nor it only caller gsskrb5importseccontext, which frees ctx on error.

Thus, this patch reform the last call of gssimportv2context to the gsskrb5importctx_v2, preventing the memleak while keepping the return formation.(CVE-2023-52653)

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

iouring: drop any code related to SCMRIGHTS

This is dead code after we dropped support for passing iouring fds over SCMRIGHTS, get rid of it.(CVE-2023-52656)

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

net: atlantic: eliminate double free in error handling logic

Driver has a logic leak in ring data allocation/free, where aqringfree could be called multiple times on same ring, if system is under stress and got memory allocation error.

Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member.

Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aqringfree on higher layer.(CVE-2023-52664)

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

ALSA: scarlett2: Add clamp() in scarlett2mixerctl_put()

Ensure the value passed to scarlett2mixerctlput() is between 0 and SCARLETT2MIXERMAXVALUE so we don't attempt to access outside scarlett2mixervalues[].(CVE-2023-52674)

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

ACPI: LPIT: Avoid u32 multiplication overflow

In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).

Change multiplication to mulu32u32().

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)

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

calipso: fix memory leak in netlblcalipsoadd_pass()

If IPv6 support is disabled at boot (ipv6.disable=1), the calipsoinit() -> netlblcalipsoopsregister() function isn't called, and the netlblcalipsoopsget() function always returns NULL. In this case, the netlblcalipsoaddpass() function allocates memory for the doidef variable but doesn't free it with the calipsodoi_free().

BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlblcalipsoaddpass net/netlabel/netlabelcalipso.c:76 [inline] [<...>] netlblcalipsoadd+0x22e/0x4f0 net/netlabel/netlabelcalipso.c:111 [<...>] genlfamilyrcvmsgdoit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genlfamilyrcvmsg net/netlink/genetlink.c:783 [inline] [<...>] genlrcvmsg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlinkrcvskb+0x14d/0x440 net/netlink/afnetlink.c:2515 [<...>] genlrcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] [<...>] netlinkunicast+0x54b/0x800 net/netlink/afnetlink.c:1339 [<...>] netlinksendmsg+0x90a/0xdf0 net/netlink/afnetlink.c:1934 [<...>] socksendmsgnosec net/socket.c:651 [inline] [<...>] socksendmsg+0x157/0x190 net/socket.c:671 [<...>] _syssendmsg+0x712/0x870 net/socket.c:2342 [<...>] syssendmsg+0xf8/0x170 net/socket.c:2396 [<...>] _syssendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] dosyscall64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entrySYSCALL64afterhwframe+0x61/0xc6

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller

PM: merged via the LSM tree at Jakub Kicinski request

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

fs/jfs: Add validity check for dbmaxag and dbagpref

Both dbmaxag and dbagpref are used as the index of the dbagfree array, but there is currently no validity check for dbmaxag and db_agpref, which can lead to errors.

The following is related bug reported by Syzbot:

UBSAN: array-index-out-of-bounds in fs/jfs/jfsdmap.c:639:20 index 7936 is out of range for type 'atomict[128]'

Add checking that the values of dbmaxag and dbagpref are valid indexes for the db_agfree array.(CVE-2023-52804)

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

jfs: fix array-index-out-of-bounds in diAlloc

Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required.(CVE-2023-52805)

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

scsi: libfc: Fix potential NULL pointer dereference in fclportptp_setup()

fclportptpsetup() did not check the return value of fcrportcreate() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fcrportcreate() and log error message on fcrport_create() failed.(CVE-2023-52809)

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

drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL

In certain types of chips, such as VEGA20, reading the amdgpuregssmc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:

1. Navigate to the directory: /sys/kernel/debug/dri/0
2. Execute command: cat amdgpuregssmc
3. Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: errorcode(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpudebugfsregssmcread+0xb0/0x120 [amdgpu] [4005007.703002] fullproxyread+0x5c/0x80 [4005007.703011] vfsread+0x9f/0x1a0 [4005007.703019] ksysread+0x67/0xe0 [4005007.703023] _x64sysread+0x19/0x20 [4005007.703028] dosyscall64+0x5c/0xc0 [4005007.703034] ? douseraddrfault+0x1e3/0x670 [4005007.703040] ? exittousermodeprepare+0x37/0xb0 [4005007.703047] ? irqentryexittousermode+0x9/0x20 [4005007.703052] ? irqentryexit+0x19/0x30 [4005007.703057] ? excpagefault+0x89/0x160 [4005007.703062] ? asmexcpagefault+0x8/0x30 [4005007.703068] entrySYSCALL64afterhwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIGRAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nftables libcrc32c nfnetlink algifhash afalg binfmtmisc nls_ iso88591 ipmissif ast intelraplmsr intelraplcommon drmvramhelper drmttmhelper amd64edac t tm edacmceamd kvmamd ccp machid k10temp kvm acpiipmi ipmisi rapl schfqcodel ipmidevintf ipm imsghandler msr parportpc ppdev lp parport mtd pstoreblk efipstore ramoops pstorezone reedsolo mon iptables xtables autofs4 ibuverbs ibcore amdgpu(OE) amddrmttmhelper(OE) amdttm(OE) iommuv 2 amdsched(OE) amdkcl(OE) drmkmshelper syscopyarea sysfillrect sysimgblt fbsysfops cec rccore drm igb ahci xhcipci libahci i2cpiix4 i2calgobit xhcipci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated---(CVE-2023-52817)

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

drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7

For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)

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

perf/core: Bail out early if the request AUX area is out of bound

When perf-record with a large AUX area, e.g 4GB, it fails with:

#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)

and it reveals a WARNING with _allocpages():

------------[ cut here ]------------
WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
Call trace:
 __alloc_pages+0x1ec/0x248
 __kmalloc_large_node+0xc0/0x1f8
 __kmalloc_node+0x134/0x1e8
 rb_alloc_aux+0xe0/0x298
 perf_mmap+0x440/0x660
 mmap_region+0x308/0x8a8
 do_mmap+0x3c0/0x528
 vm_mmap_pgoff+0xf4/0x1b8
 ksys_mmap_pgoff+0x18c/0x218
 __arm64_sys_mmap+0x38/0x58
 invoke_syscall+0x50/0x128
 el0_svc_common.constprop.0+0x58/0x188
 do_el0_svc+0x34/0x50
 el0_svc+0x34/0x108
 el0t_64_sync_handler+0xb8/0xc0
 el0t_64_sync+0x1a4/0x1a8

'rb->auxpages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAXORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING.

So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.:

#perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)

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

Input: synaptics-rmi4 - fix use after free in rmiunregisterfunction()

The putdevice() calls rmireleasefunction() which frees "fn" so the dereference on the next line "fn->numofirqs" is a use after free. Move the putdevice() to the end to fix this.(CVE-2023-52840)

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

media: vidtv: psi: Add check for kstrdup

Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)

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

tipc: Change nlapolicy for bearer-related names to NLANUL_STRING

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

===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipcnlnoderesetlinkstats+0x3ea/0xb50 net/tipc/node.c:2595 genlfamilyrcvmsgdoit net/netlink/genetlink.c:971 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1051 [inline] genlrcvmsg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlinkrcvskb+0x371/0x650 net/netlink/afnetlink.c:2545 genlrcv+0x40/0x60 net/netlink/genetlink.c:1075 netlinkunicastkernel net/netlink/afnetlink.c:1342 [inline] netlinkunicast+0xf47/0x1250 net/netlink/afnetlink.c:1368 netlinksendmsg+0x1238/0x13d0 net/netlink/afnetlink.c:1910 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:753 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2541 syssendmsg+0x28d/0x3c0 net/socket.c:2595 _syssendmsg net/socket.c:2624 [inline] _dosyssendmsg net/socket.c:2633 [inline] _sesyssendmsg net/socket.c:2631 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2631 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

Uninit was created at: slabpostallochook+0x12f/0xb70 mm/slab.h:767 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x577/0xa80 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:559 allocskb+0x318/0x740 net/core/skbuff.c:650 allocskb include/linux/skbuff.h:1286 [inline] netlinkalloclargeskb net/netlink/afnetlink.c:1214 [inline] netlinksendmsg+0xb34/0x13d0 net/netlink/afnetlink.c:1885 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:753 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2541 _syssendmsg+0x28d/0x3c0 net/socket.c:2595 _syssendmsg net/socket.c:2624 [inline] _dosyssendmsg net/socket.c:2633 [inline] _sesyssendmsg net/socket.c:2631 [inline] _x64syssendmsg+0x307/0x490 net/socket.c:2631 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x41/0xc0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue.

This patch changes the nlapolicy for bearer-related names from NLASTRING to NLANULSTRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names.

syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue.(CVE-2023-52845)

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

hsr: Prevent use after free in prpcreatetagged_frame()

The prpfillrct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value.(CVE-2023-52846)

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

media: bttv: fix use after free error due to btv->timeout timer

There may be some a race condition between timer function bttvirqtimeout and bttvremove. The timer is setup in probe and there is no timerdelete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug.

This bug is found by static analysis, it may be false positive.

Fix it by adding deltimersync invoking to the remove function.

cpu0 cpu1 bttvprobe ->timersetup ->bttvsetdma ->modtimer; bttvremove ->kfree(btv); ->bttvirqtimeout ->USE btv(CVE-2023-52847)

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

padata: Fix refcnt handling in padatafreeshell()

In a high-load arm64 environment, the pcryptaead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcryptaead01 function call, I'll describe the problem scenario using a simplified model:

Suppose there's a user of padata named user_function that adheres to the padata requirement of calling padata_free_shell after serial() has been invoked, as demonstrated in the following code:

struct request {
    struct padata_priv padata;
    struct completion *done;
};

void parallel(struct padata_priv *padata) {
    do_something();
}

void serial(struct padata_priv *padata) {
    struct request *request = container_of(padata,
                    struct request,
                padata);
    complete(request->done);
}

void user_function() {
    DECLARE_COMPLETION(done)
    padata->parallel = parallel;
    padata->serial = serial;
    padata_do_parallel();
    wait_for_completion(&done);
    padata_free_shell();
}

In the corresponding padata.c file, there's the following code:

static void padata_serial_worker(struct work_struct *serial_work) {
    ...
    cnt = 0;

    while (!list_empty(&local_list)) {
        ...
        padata->serial(padata);
        cnt++;
    }

    local_bh_enable();

    if (refcount_sub_and_test(cnt, &pd->refcnt))
        padata_free_pd(pd);
}

Because of the high system load and the accumulation of unexecuted softirq at this moment, local_bh_enable() in padata takes longer to execute than usual. Subsequently, when accessing pd->refcnt, pd has already been released by padata_free_shell(), resulting in a UAF issue with pd->refcnt.

The fix is straightforward: add refcount_dec_and_test before calling padata_free_pd in padata_free_shell.(CVE-2023-52854)

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

clk: mediatek: clk-mt7629: Add check for mtkallocclk_data

Add the check for the return value of mtkallocclk_data() in order to avoid NULL pointer dereference.(CVE-2023-52858)

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

hwmon: (axi-fan-control) Fix possible NULL pointer dereference

axifancontrolirqhandler(), dependent on the private axifancontrol_data structure, might be called before the hwmon device is registered. That will cause an "Unable to handle kernel NULL pointer dereference" error.(CVE-2023-52863)

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

drm/radeon: possible buffer overflow

Buffer 'afmtstatus' of size 6 could overflow, since index 'afmtidx' is checked after access.(CVE-2023-52867)

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

thermal: core: prevent potential string overflow

The dev->id value comes from idaalloc() so it's a number between zero and INTMAX. If it's too high then these sprintf()s will overflow.(CVE-2023-52868)

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

pstore/platform: Add check for kstrdup

Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)

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

clk: mediatek: clk-mt7629-eth: Add check for mtkallocclk_data

Add the check for the return value of mtkallocclk_data() in order to avoid NULL pointer dereference.(CVE-2023-52876)

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

tracing: Have traceeventfile have ref counters

The following can crash the kernel:

# cd /sys/kernel/tracing # echo 'p:sched schedule' > kprobeevents # exec 5>>events/kprobes/sched/enable # > kprobeevents # exec 5>&-

The above commands:

1. Change directory to the tracefs directory
2. Create a kprobe event (doesn't matter what one)
3. Open bash file descriptor 5 on the enable file of the kprobe event
4. Delete the kprobe event (removes the files too)
5. Close the bash file descriptor 5

The above causes a crash!

BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:tracingreleasefiletr+0xc/0x50

What happens here is that the kprobe event creates a traceeventfile "file" descriptor that represents the file in tracefs to the event. It maintains state of the event (is it enabled for the given instance?). Opening the "enable" file gets a reference to the event "file" descriptor via the open file descriptor. When the kprobe event is deleted, the file is also deleted from the tracefs system which also frees the event "file" descriptor.

But as the tracefs file is still opened by user space, it will not be totally removed until the final dput() is called on it. But this is not true with the event "file" descriptor that is already freed. If the user does a write to or simply closes the file descriptor it will reference the event "file" descriptor that was just freed, causing a use-after-free bug.

To solve this, add a ref count to the event "file" descriptor as well as a new flag called "FREED". The "file" will not be freed until the last reference is released. But the FREE flag will be set when the event is removed to prevent any more modifications to that event from happening, even if there's still a reference to the event "file" descriptor.(CVE-2023-52879)

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

netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout

While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path.

Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout").

Fix this by setting on the dead flag for anonymous sets to skip async gc in this case.

According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.(CVE-2024-26643)

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

wireguard: netlink: access device through ctx instead of peer

The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peerallowedips.seq is compared with ctx->allowedipsseq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.(CVE-2024-26950)

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

nilfs2: prevent kernel bug at submitbhwbc()

Fix a bug where nilfsgetblock() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead.

This prevents callers such as _blockwritebeginint() from requesting a read into a buffer that is not mapped, which would cause the BUGON check for the BHMapped flag in submitbhwbc() to fail.(CVE-2024-26955)

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

s390/zcrypt: fix reference counting on zcrypt card objects

Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use.

This is an example of the slab message:

kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
kernel:  kmalloc_trace+0x3f2/0x470
kernel:  zcrypt_card_alloc+0x36/0x70 [zcrypt]
kernel:  zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
kernel:  ap_device_probe+0x15c/0x290
kernel:  really_probe+0xd2/0x468
kernel:  driver_probe_device+0x40/0xf0
kernel:  __device_attach_driver+0xc0/0x140
kernel:  bus_for_each_drv+0x8c/0xd0
kernel:  __device_attach+0x114/0x198
kernel:  bus_probe_device+0xb4/0xc8
kernel:  device_add+0x4d2/0x6e0
kernel:  ap_scan_adapter+0x3d0/0x7c0
kernel:  ap_scan_bus+0x5a/0x3b0
kernel:  ap_scan_bus_wq_callback+0x40/0x60
kernel:  process_one_work+0x26e/0x620
kernel:  worker_thread+0x21c/0x440
kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
kernel:  kfree+0x37e/0x418
kernel:  zcrypt_card_put+0x54/0x80 [zcrypt]
kernel:  ap_device_remove+0x4c/0xe0
kernel:  device_release_driver_internal+0x1c4/0x270
kernel:  bus_remove_device+0x100/0x188
kernel:  device_del+0x164/0x3c0
kernel:  device_unregister+0x30/0x90
kernel:  ap_scan_adapter+0xc8/0x7c0
kernel:  ap_scan_bus+0x5a/0x3b0
kernel:  ap_scan_bus_wq_callback+0x40/0x60
kernel:  process_one_work+0x26e/0x620
kernel:  worker_thread+0x21c/0x440
kernel:  kthread+0x150/0x168
kernel:  __ret_from_fork+0x3c/0x58
kernel:  ret_from_fork+0xa/0x30
kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
kernel: Redzone  00000000885a74b0: bb bb bb bb bb bb bb bb                          ........
kernel: Object   00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
kernel: Object   00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
kernel: Object   00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
kernel: Object   00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
kernel: Object   00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
kernel: Object   00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5  kkkkkkkkkkhKkkk.
kernel: Redzone  00000000885a7518: bb bb bb bb bb bb bb bb                          ........
kernel: Padding  00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
kernel: Call Trace:
kernel:  [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
kernel:  [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
kernel:  [<00000000c99d53cc>] check_object+0x334/0x3f8
kernel:  [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
kernel:  [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
kernel:  [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
kernel:  [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
kernel:  [<00000000c99dc8dc>] __kmalloc+0x434/0x590
kernel:  [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
kernel:  [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
kernel:

---truncated---(CVE-2024-26957)

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

nfs: fix UAF in direct writes

In production we have been hitting the following warning consistently

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcountwarnsaturate+0x9c/0xe0 Workqueue: nfsiod nfsdirectwriteschedulework [nfs] RIP: 0010:refcountwarnsaturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? _warn+0x9f/0x130 ? refcountwarnsaturate+0x9c/0xe0 ? reportbug+0xcc/0x150 ? handlebug+0x3d/0x70 ? excinvalidop+0x16/0x40 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0x9c/0xe0 nfsdirectwriteschedulework+0x237/0x250 [nfs] processonework+0x12f/0x4a0 workerthread+0x14e/0x3b0 ? ZSTDgetCParamsinternal+0x220/0x220 kthread+0xdc/0x120 ? _btfnamevalid+0xa0/0xa0 retfrom_fork+0x1f/0x30

This is because we're completing the nfsdirectrequest twice in a row.

The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have

if (nfscommitend(cinfo.mds)) nfsdirectwrite_complete(dreq);

However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfsdirectrequest twice.

The only other place we use nfsgenericcommitlist() is in _nfscommitinode, which wraps this call in a

nfscommitbegin(); nfscommitend();

Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with getdreq()/putdreq() calls around where we process events as well as in the completion paths.

Fix this by using the same pattern for the commit requests.

Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.(CVE-2024-26958)

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

mac802154: fix llsec key resources release in mac802154llseckey_del

mac802154llseckeydel() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llseclookup_key() is traversing the list of keys in parallel with a key deletion:

refcountt: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcountwarnsaturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcountwarnsaturate+0x162/0x2a0 Call Trace: <TASK> llseclookupkey.isra.0+0x890/0x9e0 mac802154llsecencrypt+0x30c/0x9c0 ieee802154subifstartxmit+0x24/0x1e0 devhardstartxmit+0x13e/0x690 schdirectxmit+0x2ae/0xbc0 _devqueuexmit+0x11dd/0x3c20 dgramsendmsg+0x90b/0xd60 _syssendto+0x466/0x4c0 _x64syssendto+0xe0/0x1c0 dosyscall64+0x45/0xf0 entrySYSCALL64afterhwframe+0x6e/0x76

Also, ieee802154llseckeyentry structures are not freed by mac802154llseckeydel():

unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] kmemcacheallocnode+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloctrace+0x25/0xc0 [<ffffffff88968b09>] mac802154llseckeyadd+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154addllseckey+0x5a/0x80 [<ffffffff8892adc6>] nl802154addllseckey+0x426/0x5b0 [<ffffffff86ff293e>] genlfamilyrcvmsgdoit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genlrcvmsg+0x531/0x7d0 [<ffffffff86fee7a9>] netlinkrcvskb+0x169/0x440 [<ffffffff86ff1d88>] genlrcv+0x28/0x40 [<ffffffff86fec15c>] netlinkunicast+0x53c/0x820 [<ffffffff86fecd8b>] netlinksendmsg+0x93b/0xe60 [<ffffffff86b91b35>] syssendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] _syssendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] _syssendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] dosyscall64+0x45/0xf0 [<ffffffff890000ea>] entrySYSCALL64afterhwframe+0x6e/0x76

Handle the proper resource release in the RCU callback function mac802154llseckeydelrcu().

Note that if llseclookupkey() finds a key, it gets a refcount via llseckeyget() and locally copies key id from keyentry (which is a list element). So it's safe to call llseckey_put() and free the list entry after the RCU grace period elapses.

Found by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)

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

clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcomfindfreq() or qcomfindfreq_floor().

Only compile tested.(CVE-2024-26965)

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

ubifs: ubifssymlink: Fix memleak of inode->ilink in error path

For error handling path in ubifssymlink(), inode will be marked as bad first, then iput() is invoked. If inode->ilink is initialized by fscryptencryptsymlink() in encryption scenario, inode->ilink won't be freed by callchain ubifsfreeinode -> fscryptfreeinode in error handling path, because makebadinode() has changed 'inode->imode' as 'SIFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifsjnlupdate() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 _fscryptencryptsymlink+0xed/0x1c0 ubifssymlink+0x210/0x300 [ubifs] vfssymlink+0x216/0x360 dosymlinkat+0x11a/0x190 dosyscall64+0x3b/0xe0 There are two ways fixing it: 1. Remove makebadinode() in error handling path. We can do that because ubifsevictinode() will do same processes for good symlink inode and bad symlink inode, for inode->inlink checking is before isbadinode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think.(CVE-2024-26972)

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

KVM: Always flush async #PF workqueue when vCPU is being destroyed

Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM module is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes.

Drop the misguided VM refcount gifting, as calling kvmputkvm() from asyncpfexecute() if kvmputkvm() flushes the async #PF workqueue will result in deadlock. asyncpfexecute() can't return until kvmputkvm() finishes, and kvmputkvm() can't return until asyncpfexecute() finishes:

WARNING: CPU: 8 PID: 251 at virt/kvm/kvmmain.c:1435 kvmputkvm+0x2d/0x320 [kvm] Modules linked in: vhostnet vhost vhostiotlb tap kvmintel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events asyncpfexecute [kvm] RIP: 0010:kvmputkvm+0x2d/0x320 [kvm] Call Trace: <TASK> asyncpfexecute+0x198/0x260 [kvm] processonework+0x145/0x2d0 workerthread+0x27e/0x3a0 kthread+0xba/0xe0 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events asyncpfexecute [kvm] Call Trace: <TASK> _schedule+0x33f/0xa40 schedule+0x53/0xc0 scheduletimeout+0x12a/0x140 _waitforcommon+0x8d/0x1d0 _flushwork.isra.0+0x19f/0x2c0 kvmclearasyncpfcompletionqueue+0x129/0x190 [kvm] kvmarchdestroyvm+0x78/0x1b0 [kvm] kvmputkvm+0x1c1/0x320 [kvm] asyncpfexecute+0x198/0x260 [kvm] processonework+0x145/0x2d0 workerthread+0x27e/0x3a0 kthread+0xba/0xe0 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20 </TASK>

If kvmclearasyncpfcompletionqueue() actually flushes the workqueue, then there's no need to gift asyncpfexecute() a reference because all invocations of asyncpfexecute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as _fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module.

Note that kvmcheckasyncpfcompletion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvmclearasyncpfcompletionqueue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvmarchasyncpagepresentqueued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just:

    trace_kvm_async_pf_completed(addr, cr2_or_gpa);

    __kvm_vcpu_wake_up(vcpu);

    mmput(mm);

and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables.

Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes _flushwork() complain (kudos to whoever added that sanity check).

Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---(CVE-2024-26976)

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

Squashfs: check the inode number is not the invalid value of zero

Syskiller has produced an out of bounds access in fillmetaindex().

That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked.

The reason this causes the out of bounds access is due to following sequence of events:

1. Fillmetaindex() is called to allocate (via emptymetaindex()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).

2. When fillmetaindex() is subsequently called again on another read operation, locatemetaindex() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.

This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is.

[phillip@squashfs.org.uk: whitespace fix] Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)

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

fs: sysfs: Fix reference leak in sysfsbreakactive_protection()

The sysfsbreakactiveprotection() routine has an obvious reference leak in its error path. If the call to kernfsfindandget() fails then kn will be NULL, so the companion sysfsunbreakactive_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released.

Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)

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

speakup: Avoid crash on very long word

In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)

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

serial/pmac_zilog: Remove flawed mitigation for rx irq flood

The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console:

ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0

That's because the prerr() call in pmzreceivechars() results in pmzconsolewrite() attempting to lock a spinlock already locked in pmzinterrupt(). With CONFIGDEBUGSPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port.

Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below.

A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.(CVE-2024-26999)

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

serial: mxs-auart: add spinlock around changing cts state

The uarthandlectschange() function in serialcore expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board.

[   85.119255] ------------[ cut here ]------------
[   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
[   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
[   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
[   85.151396] Hardware name: Freescale MXS (Device Tree)
[   85.156679] Workqueue: hci0 hci_power_on [bluetooth]
(...)
[   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
[   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
(...)(CVE-2024-27000)

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

drm: nv04: Fix out of bounds access

When Output Resource (dcb->or) value is assigned in fabricatedcboutput(), there may be out of bounds access to dacusers array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricatedcb_output() must be interpreted as a number of bit to set, not value.

Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.

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

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

net/sched: Fix mirred deadlock on device recursion

When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.

[..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: _devqueuexmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: _devqueuexmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] * DEADLOCK * [ 82.890906] [..... other info removed for brevity....]

Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0

Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1

tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0

We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)

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

netfilter: nf_tables: fix memleak in map from abort path

The delete set command does not rely on the transaction object for element removal, therefore, a combination of delete element + delete set from the abort path could result in restoring twice the refcount of the mapping.

Check for inactive element in the next generation for the delete element command in the abort path, skip restoring state if next generation bit has been already cleared. This is similar to the activate logic using the set walk iterator.

[ 6170.286929] ------------[ cut here ]------------ [ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nftablesapi.c:2086 nftableschaindestroy+0x1f7/0x220 [nftables] [ 6170.287071] Modules linked in: [...] [ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365 [ 6170.287768] RIP: 0010:nftableschaindestroy+0x1f7/0x220 [nftables] [ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f [ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202 [ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000 [ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750 [ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55 [ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10 [ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100 [ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000 [ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0 [ 6170.287962] Call Trace: [ 6170.287967] <TASK> [ 6170.287973] ? _warn+0x9f/0x1a0 [ 6170.287986] ? nftableschaindestroy+0x1f7/0x220 [nftables] [ 6170.288092] ? reportbug+0x1b1/0x1e0 [ 6170.287986] ? nftableschaindestroy+0x1f7/0x220 [nftables] [ 6170.288092] ? reportbug+0x1b1/0x1e0 [ 6170.288104] ? handlebug+0x3c/0x70 [ 6170.288112] ? excinvalidop+0x17/0x40 [ 6170.288120] ? asmexcinvalidop+0x1a/0x20 [ 6170.288132] ? nftableschaindestroy+0x2b/0x220 [nftables] [ 6170.288243] ? nftableschaindestroy+0x1f7/0x220 [nftables] [ 6170.288366] ? nftableschaindestroy+0x2b/0x220 [nftables] [ 6170.288483] nftablestransdestroywork+0x588/0x590 nftables

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

net/rds: fix WARNING in rdsconnconnectifdown

If connection isn't established yet, getmr() will fail, trigger connection after getmr().(CVE-2024-27024)

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

f2fs: compress: fix to cover normal cluster write with cp_rwsem

When we overwrite compressed cluster w/ normal cluster, we should not unlock cprwsem during f2fswriterawpages(), otherwise data will be corrupted if partial blocks were persisted before CP & SPOR, due to cluster metadata wasn't updated atomically.(CVE-2024-27034)

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

f2fs: compress: fix to guarantee persisting compressed blocks by CP

If data block in compressed cluster is not persisted with metadata during checkpoint, after SPOR, the data may be corrupted, let's guarantee to write compressed page by checkpoint.(CVE-2024-27035)

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

clk: zynq: Prevent null pointer dereference caused by kmalloc failure

The kmalloc() in zynqclksetup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen.

This patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)

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

drm/amd/display: Fix a potential buffer overflow in 'dpdscclockenread()'

Tell snprintf() to store at most 10 bytes in the output buffer instead of 30.

Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpudm/amdgpudmdebugfs.c:1508 dpdscclocken_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)

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

USB: usb-storage: Prevent divide-by-0 error in isd200atacommand

The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer.

Protect against this possibility by refusing to bind to the device if either the ATAIDHEADS or ATAIDSECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error).(CVE-2024-27059)

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

media: usbtv: Remove useless locks in usbtvvideofree()

Remove locks calls in usbtvvideofree() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device.

Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming.

hverkuil: fix minor spelling mistake in log message

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

media: ttpci: fix two memleaks in budgetavattach

When saa7146registerdevice and saa7146vvinit fails, budgetavattach should free the resources it allocates, like the error-handling of ttpcibudgetinit does. Besides, there are two fixme comment refers to such deallocations.(CVE-2024-27073)

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

media: dvb-frontends: avoid stack overflow warnings with clang

A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang:

drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367tersetfrontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367tersetfrontend(struct dvb_frontend *fe)

Rework the stv0367writereg() function to be simpler and mark both register access functions as noinlineforstack so the temporary i2cmsg structures do not get duplicated on the stack when KASAN_STACK is enabled.(CVE-2024-27075)

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

SUNRPC: fix some memleaks in gssxdecoption_array

The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.(CVE-2024-27388)

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

pstore: inode: Only d_invalidate() is needed

Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning:

WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410

Using the combo of ddrop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use dinvalidate() and update the code to not bother checking for error codes that can never happen.

---(CVE-2024-27389)

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

netfilter: nftflowoffload: reset dst in route object after setting up flow

dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flowoffloadadd() fails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)

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

fs/ntfs3: Fixed overflow check in mienumattr()(CVE-2024-27407)

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

netrom: Fix data-races around sysctlnetbusy_read

We need to protect the reader reading the sysctl value because the value can be changed concurrently.(CVE-2024-27419)

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

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

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

In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfdstate in sync with MSRIA32XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfdstate to keep the MSRIA32XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSRIA32XFD is reset to the initfpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfdupdatestate() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfdsetstate() to write xfdstate together with MSRIA32XFD, and use it in all places that set MSRIA32XFD.(CVE-2024-35801)

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

dm snapshot: fix lockup in dmexceptiontable_exit

There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.(CVE-2024-35805)

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

soc: fsl: qbman: Always disable interrupts when taking cgr_lock

smpcallfunctionsingle disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgrlock elsewhere. This is already done by qmanupdatecgr and qmandeletecgr; fix the other lockers.(CVE-2024-35806)

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

fs/aio: Check IOCBAIORW before the struct aio_kiocb conversion

The first kiocbsetcancelfn() argument may point at a struct kiocb that is not embedded inside struct aiokiocb. With the current code, depending on the compiler, the req->kictx read happens either before the IOCBAIORW test or after that test. Move the req->kictx read such that it is guaranteed that the IOCBAIORW test happens first.(CVE-2024-35815)

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

drm/amdgpu: amdgputtmgart_bind set gtt bound flag

Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgputtmbackend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)

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

LoongArch: Define the _ioaw() hook as mmiowb()

Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says:

"NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spinunlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spinunlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation."

The mmio in radeonringcommit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio.

So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the _ioaw() hook as mmiowb(). And we no longer need to override queuedspinunlock() so use the generic definition.

Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch:

radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeongemvaioctl [radeon]] *ERROR* Couldn't update BOVA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeongemvaioctl [radeon]] *ERROR* Couldn't update BOVA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeongemvaioctl [radeon]] *ERROR* Couldn't update BOVA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeongemvaioctl [radeon]] *ERROR* Couldn't update BOVA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeongemvaioctl [radeon]] *ERROR* Couldn't update BOVA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeongemvaioctl [radeon]] *ERROR* Couldn't update BOVA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeongemvaioctl [radeon]] *ERROR* Couldn't update BOVA (-35)(CVE-2024-35818)

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

net/mlx5e: fix a double-free in arfscreategroups

When in allocated by kvzalloc fails, arfscreategroups will free ft->g and return an error. However, arfscreatetable, the only caller of arfscreategroups, will hold this error and call to mlx5edestroyflow_table, in which the ft->g will be freed again.(CVE-2024-35835)

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

netfilter: bridge: replace physindev with physinif in nfbridgeinfo

An skb can be added to a neigh->arpqueue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arpqueue of the bridge.

As skb->dev can be reset back to nfbridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neighflush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:

arpprocess neighupdate skb = _skbdequeue(&neigh->arpqueue) neighresolveoutput(..., skb) ... brnfdevxmit brnfpreroutingfinishbridgeslow skb->dev = nfbridge->physindev brhandleframefinish

Let's use plain ifindex instead of netdevice link. To peek into the original netdevice we will use devgetbyindexrcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.(CVE-2024-35839)

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

f2fs: compress: fix reserve_cblocks counting error when out of space

When a file only needs one direct_node, performing the following operations will cause the file to be unrepairable:

unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data

unisoc # ./f2fsio releasecblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4.8M 100% /data

unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data

unisoc # ./f2fsio reservecblocks test.apk F2FSIOCRESERVECOMPRESSBLOCKS failed: No space left on device

adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fsio reservecblocks test.apk 0

This is because the file has only one directnode. After returning to -ENOSPC, reservedblocks += ret will not be executed. As a result, the reserved_blocks at this time is still 0, which is not the real number of reserved blocks. Therefore, fsck cannot be set to repair the file.

After this patch, the fsck flag will be set to fix this problem.

unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fsio reservecblocks test.apk F2FSIOCRESERVECOMPRESSBLOCKS failed: No space left on device

adb reboot then fsck will be executed unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fsio reservecblocks test.apk 924(CVE-2024-35844)

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

eeprom: at24: fix memory corruption race condition

If the eeprom is not accessible, an nvmem device will be registered, the read will fail, and the device will be torn down. If another driver accesses the nvmem device after the teardown, it will reference invalid memory.

Move the failure point before registering the nvmem device.(CVE-2024-35848)

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

ipv6: Fix infinite recursion in fib6dumpdone().

syzkaller reported infinite recursive calls of fib6dumpdone() during netlink socket destruction. [1]

From the log, syzkaller sent an AFUNSPEC RTMGETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6dumpfib() failed at kzalloc() due to the fault injection. [0]

12:01:34 executing program 3: r0 = socket$nlroute(0x10, 0x3, 0x0) sendmsg$nlroute(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8)

Here, fib6dumpdone() was set to nlksk(sk)->cb.done, and the next call of inet6dumpfib() set it to nlksk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlinksockdestruct() called nlk_sk(sk)->cb.done().

fib6dumpdone() calls fib6dumpend() and nlksk(sk)->cb.done() if it is still not NULL. fib6dumpend() rewrites nlksk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page.

To avoid the issue, let's set the destructor after kzalloc().

name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:117) shouldfailex (lib/fault-inject.c:52 lib/fault-inject.c:153) shouldfailslab (mm/slub.c:3733) kmalloctrace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6dumpfib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6fib.c:662) rtnldumpall (net/core/rtnetlink.c:4029) netlinkdump (net/netlink/afnetlink.c:2269) netlinkrecvmsg (net/netlink/afnetlink.c:1988) _sysrecvmsg (net/socket.c:1046 net/socket.c:2801) sysrecvmsg (net/socket.c:2846) dorecvmmsg (net/socket.c:2943) _x64sysrecvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)

stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlinksockdestructwork RIP: 0010:fib6dumpdone (net/ipv6/ip6fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) ... fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) netlinksockdestruct (net/netlink/afnetlink.c:401) _skdestruct (net/core/sock.c:2177 (discriminator 2)) skdestruct (net/core/sock.c:2224) _skfree (net/core/sock.c:2235) skfree (net/core/sock.c:2246) processonework (kernel/workqueue.c:3259) workerthread (kernel/workqueue.c:3329 kernel/workqueue. ---truncated---(CVE-2024-35886)

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

netfilter: nf_tables: discard table flag update with pending basechain deletion

Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.(CVE-2024-35897)

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

netfilter: nftables: Fix potential data-race in _nftflowtabletype_get()

nftunregisterflowtabletype() within nfflowinetmoduleexit() can concurrent with _nftflowtabletypeget() within nftablesnewflowtable(). And thhere is not any protection when iterate over nftablesflowtables list in _nftflowtabletypeget(). Therefore, there is pertential data-race of nftables_flowtables list entry.

Use listforeachentryrcu() to iterate over nftablesflowtables list in _nftflowtabletypeget(), and use rcureadlock() in the caller nftflowtabletype_get() to protect the entire type query process.(CVE-2024-35898)

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

fbmon: prevent division by zero in fbvideomodefrom_videomode()

The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fbvarto_videomode().

Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)

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

scsi: lpfc: Fix possible memory leak in lpfcrcvpadisc()

The call to lpfcsli4resumerpi() in lpfcrcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.

Check return value after calling lpfcsli4resume_rpi() and conditionally release the elsiocb resource.(CVE-2024-35930)

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

btrfs: handle chunk tree lookup error in btrfsrelocatesys_chunks()

The unhandled case in btrfsrelocatesys_chunks() loop is a corruption, as it could be caused only by two impossible conditions:

• at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1

• after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints(CVE-2024-35936)

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

pstore/zone: Add a null pointer check to the pszkmsgread

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.(CVE-2024-35940)

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

xsk: validate user input for XDP{UMEM|COMPLETION}FILL_RING

syzbot reported an illegal copy in xsk_setsockopt() [1]

Make sure to validate setsockopt() @optlen parameter.

[1]

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsksetsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549

CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #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 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] xsksetsockopt+0x909/0xa40 net/xdp/xsk.c:1420 dosocksetsockopt+0x3af/0x720 net/socket.c:2311 _syssetsockopt+0x1ae/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfb/0x240 entrySYSCALL64afterhwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIGRAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 </TASK>

Allocated by task 7549: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:370 [inline] _kasankmalloc+0x98/0xb0 mm/kasan/common.c:387 kasankmalloc include/linux/kasan.h:211 [inline] _dokmallocnode mm/slub.c:3966 [inline] _kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] _cgroupbpfrunfiltersetsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 dosocksetsockopt+0x6b4/0x720 net/socket.c:2293 _syssetsockopt+0x1ae/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfb/0x240 entrySYSCALL64after_hwframe+0x6d/0x75

The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)

The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) pagetype: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected pageowner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfpmask 0x112cc0(GFPUSER|GFPNOWARN|GFPNORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, freets 133859922223 setpageowner include/linux/pageowner.h:31 [inline] postallochook+0x1ea/0x210 mm/pagealloc.c:1533 prepnewpage mm/pagealloc.c: ---truncated---(CVE-2024-35976)

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

ACPI: CPPC: Use accesswidth over bitwidth for system memory accesses

To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform.

SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppcgetperfcaps+0xec/0x410 lr : cppcgetperfcaps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dumpbacktrace+0x0/0x1e0 showstack+0x24/0x30 dumpstacklvl+0x8c/0xb8 dumpstack+0x18/0x34 panic+0x16c/0x384 addtaint+0x0/0xc0 arm64serrorpanic+0x7c/0x90 arm64isfatalrasserror+0x34/0xa4 doserror+0x50/0x6c el1h64errorhandler+0x40/0x74 el1h64error+0x7c/0x80 cppcgetperfcaps+0xec/0x410 cppccpufreqcpuinit+0x74/0x400 [cppccpufreq] cpufreqonline+0x2dc/0xa30 cpufreqadddev+0xc0/0xd4 subsysinterfaceregister+0x134/0x14c cpufreqregisterdriver+0x1b0/0x354 cppccpufreqinit+0x1a8/0x1000 [cppccpufreq] dooneinitcall+0x50/0x250 doinitmodule+0x60/0x27c loadmodule+0x2300/0x2570 _dosysfinitmodule+0xa8/0x114 _arm64sysfinitmodule+0x2c/0x3c invokesyscall+0x78/0x100 el0svccommon.constprop.0+0x180/0x1a0 doel0svc+0x84/0xa0 el0svc+0x2c/0xc0 el0t64synchandler+0xa4/0x12c el0t64_sync+0x1a4/0x1a8

Instead, use accesswidth to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the accesswidth to subspace id.

If accesswidth is not set, then fall back to using bitwidth.

rjw: Subject and changelog edits, comment adjustments

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

HID: i2c-hid: remove I2CHIDREAD_PENDING flag to prevent lock-up

The flag I2CHIDREAD_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that.

More importantly, this flag can cause a lock-up: if the flag is set in i2chidxfer() and an interrupt happens, the interrupt handler (i2chidirq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop.

Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up.

Delete this unnecessary flag.(CVE-2024-35997)

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

mlxsw: spectrumacltcam: Fix incorrect list API usage

Both the function that migrates all the chunks within a region and the function that migrates all the entries within a chunk call listfirstentry() on the respective lists without checking that the lists are not empty. This is incorrect usage of the API, which leads to the following warning [1].

Fix by returning if the lists are empty as there is nothing to migrate in this case.

[1] WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrumacltcam.c:1266 mlxswspacltcamvchunkmigrateall+0x1f1/0> Modules linked in: CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:mlxswspacltcamvchunkmigrateall+0x1f1/0x2c0 [...] Call Trace: <TASK> mlxswspacltcamvregionrehashwork+0x6c/0x4a0 processonework+0x151/0x370 workerthread+0x2cb/0x3e0 kthread+0xd0/0x100 retfromfork+0x34/0x50 retfromfork_asm+0x1a/0x30 </TASK>(CVE-2024-36006)

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

ipv4: check for NULL idev in iprouteuse_hint()

syzbot was able to trigger a NULL deref in fibvalidatesource() in an old tree [1].

It appears the bug exists in latest trees.

All calls to _indevgetrcu() must be checked for a NULL result.

[1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fibvalidatesource+0xbf/0x15a0 net/ipv4/fibfrontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iprouteusehint+0x410/0x9b0 net/ipv4/route.c:2231 iprcvfinishcore+0x2c4/0x1a30 net/ipv4/ipinput.c:327 iplistrcvfinish net/ipv4/ipinput.c:612 [inline] ipsublistrcv+0x3ed/0xe50 net/ipv4/ipinput.c:638 iplistrcv+0x422/0x470 net/ipv4/ipinput.c:673 _netifreceiveskblistptype net/core/dev.c:5572 [inline] _netifreceiveskblistcore+0x6b1/0x890 net/core/dev.c:5620 _netifreceiveskblist net/core/dev.c:5672 [inline] netifreceiveskblistinternal+0x9f9/0xdc0 net/core/dev.c:5764 netifreceiveskblist+0x55/0x3e0 net/core/dev.c:5816 xdprecvframes net/bpf/testrun.c:257 [inline] xdptestrunbatch net/bpf/testrun.c:335 [inline] bpftestrunxdplive+0x1818/0x1d00 net/bpf/testrun.c:363 bpfprogtestrunxdp+0x81f/0x1170 net/bpf/testrun.c:1376 bpfprogtestrun+0x349/0x3c0 kernel/bpf/syscall.c:3736 _sysbpf+0x45c/0x710 kernel/bpf/syscall.c:5115 _dosysbpf kernel/bpf/syscall.c:5201 [inline] _sesysbpf kernel/bpf/syscall.c:5199 [inline] _x64sysbpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)