OESA-2024-1681

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:

pinctrl: single: fix potential NULL dereference

Added checking of pointer "function" in pcssetmux(). pinmuxgenericget_function() can return NULL and the pointer "function" was dereferenced without checking against NULL.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)

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:

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:

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:

crypto: pcrypt - Fix hungtask for PADATA_RESET

We found a hungtask bug in testaeadvec_cfg as follows:

INFO: task cryptomgrtest:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. Call trace: _switchto+0x98/0xe0 _schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 scheduletimeout+0x474/0x560 waitforcommon+0x368/0x4e0 waitforcompletion+0x20/0x30 waitforcompletion+0x20/0x30 testaeadveccfg+0xab4/0xd50 testaead+0x144/0x1f0 algtestaead+0xd8/0x1e0 algtest+0x634/0x890 cryptomgrtest+0x40/0x70 kthread+0x1e0/0x220 retfromfork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks

For padatadoparallel, when the return err is 0 or -EBUSY, it will call waitforcompletion(&wait->completion) in testaeadveccfg. In normal case, aeadrequestcomplete() will be called in pcryptaeadserial and the return err is 0 for padatadoparallel. But, when pinst->flags is PADATARESET, the return err is -EBUSY for padatadoparallel, and it won't call aeadrequestcomplete(). Therefore, testaeadveccfg will hung at waitfor_completion(&wait->completion), which will cause hungtask.

The problem comes as following: (padatadoparallel) | rcureadlockbh(); | err = -EINVAL; | (padatareplace) | pinst->flags |= PADATARESET; err = -EBUSY | if (pinst->flags & PADATARESET) | rcureadunlock_bh() | return err

In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again.

v3: remove retry and just change the return err. v2: introduce padatatrydoparallel() in pcryptaeadencrypt and pcryptaead_decrypt to solve the hungtask.(CVE-2023-52813)

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:

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:

nbd: fix uaf in nbd_open

Commit 4af5f2e03013 ("nbd: use blkmqallocdisk and blkcleanupdisk") cleans up disk by blkcleanupdisk() and it won't set disk->privatedata as NULL as before. UAF may be triggered in nbdopen() if someone tries to open nbd device right after nbdput() since nbd has been free in nbddevremove().

Fix this by implementing ->free_disk and free private data in it.(CVE-2023-52837)

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:

drivers/perf: hisi: use cpuhpstateremoveinstancenocalls() for hisihns3pmu uninit process

When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug callbacks after the device has been unregistered, leading to fireworks when we try to execute empty function callbacks within the driver:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G W O 5.12.0-rc4+ #1 | Hardware name: , BIOS KpxxxFPGA 1P B600 V143 04/22/2021 | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) | pc : perfpmumigratecontext+0x98/0x38c | lr : perfpmumigratecontext+0x94/0x38c | | Call trace: | perfpmumigratecontext+0x98/0x38c | hisihns3pmuofflinecpu+0x104/0x12c [hisihns3_pmu]

Use cpuhpstateremoveinstancenocalls() instead of cpuhpstateremove_instance() so that the notifiers don't execute after the PMU device has been unregistered.

will: Rewrote commit message

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:

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:

mmc: mmci: stm32: fix DMA API overlapping mappings warning

Turning on CONFIGDMAAPIDEBUGSG results in the following warning:

DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 adddmaentry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: eventsfreezable mmcrescan Call trace: adddmaentry+0x234/0x2f4 debugdmamapsg+0x198/0x350 _dmamapsgattrs+0xa0/0x110 dmamapsgattrs+0x10/0x2c sdmmcidmaprepdata+0x80/0xc0 mmciprepdata+0x38/0x84 mmcistartdata+0x108/0x2dc mmcirequest+0xe4/0x190 _mmcstartrequest+0x68/0x140 mmcstartrequest+0x94/0xc0 mmcwaitforreq+0x70/0x100 mmcsendtuning+0x108/0x1ac sdmmcexecutetuning+0x14c/0x210 mmcexecutetuning+0x48/0xec mmcsdinituhscard.part.0+0x208/0x464 mmcsdinitcard+0x318/0x89c mmcattachsd+0xe4/0x180 mmcrescan+0x244/0x320

DMA API debug brings to light leaking dma-mappings as dmamapsg and dmaunmapsg are not correctly balanced.

If an error occurs in mmcicmdirq function, only mmcidmaerror function is called and as this API is not managed on stm32 variant, dmaunmapsg is never called in this error path.(CVE-2024-26787)

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

Bluetooth: Avoid potential use-after-free in hcierrorreset

While handling the HCIEVHARDWAREERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hcidev and lead to a use-after-free in hcierrorreset.

Here's the call trace observed on a ChromeOS device with Intel AX201: queueworkon+0x3e/0x6c _hcicmdsyncsk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? initwaitentry+0x31/0x31 _hcicmdsync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hcierrorreset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] processonework+0x1d8/0x33f workerthread+0x21b/0x373 kthread+0x13a/0x152 ? prcontwork+0x54/0x54 ? kthreadblkcg+0x31/0x31 retfrom_fork+0x1f/0x30

This patch holds the reference count on the hcidev while processing a HCIEVHARDWAREERROR event to avoid potential crash.(CVE-2024-26801)

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

vfio/fsl-mc: Block calling interrupt handler without trigger

The eventfdctx trigger pointer of the vfiofslmcirq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between requestirq() and freeirq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive.

The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)

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

net: hns3: fix kernel crash when 1588 is received on HIP08 devices

The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3RXDTSVLDB bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash:

[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclgeptpgetrxhwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclgeptpgetrxhwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclgeptpgetrxhwts+0x40/0x170 [hclge] [ 5889.388304] hns3handlebdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3handlerxbd+0x60/0x150 [hns3] [ 5889.399624] hns3cleanrxring+0x84/0x170 [hns3] [ 5889.405270] hns3niccommonpoll+0xa8/0x220 [hns3] [ 5889.411084] napipoll+0xcc/0x264 [ 5889.415329] netrxaction+0xd4/0x21c [ 5889.419911] _dosoftirq+0x130/0x358 [ 5889.424484] irqexit+0x134/0x154 [ 5889.428700] _handledomainirq+0x88/0xf0 [ 5889.433684] gichandleirq+0x78/0x2c0 [ 5889.438319] el1irq+0xb8/0x140 [ 5889.442354] archcpuidle+0x18/0x40 [ 5889.446816] defaultidlecall+0x5c/0x1c0 [ 5889.451714] cpuidleidlecall+0x174/0x1b0 [ 5889.456692] doidle+0xc8/0x160 [ 5889.460717] cpustartupentry+0x30/0xfc [ 5889.465523] secondarystartkernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel...(CVE-2024-26881)

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

af_unix: Fix garbage collector racing against connect()

Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCMRIGHTS, two consecutive passes of scanchildren() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gcinflightlist.

sockets are AFUNIX/SOCKSTREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped

connect(S, addr) sendmsg(S, [V]); close(V) _unixgc() ---------------- ------------------------- -----------

NS = unixcreate1() skb1 = sockwmalloc(NS) L = unixfindother(addr) unixstatelock(L) unix_peer(S) = NS // V count=1 inflight=0

        NS = unix_peer(S)
        skb2 = sock_alloc()
        skb_queue_tail(NS, skb2[V])

        // V became in-flight
        // V count=2 inflight=1

        close(V)

        // V count=1 inflight=1
        // GC candidate condition met

                    for u in gc_inflight_list:
                      if (total_refs == inflight_refs)
                        add u to gc_candidates

                    // gc_candidates={L, V}

                    for u in gc_candidates:
                      scan_children(u, dec_inflight)

                    // embryo (skb1) was not
                    // reachable from L yet, so V's
                    // inflight remains unchanged

_skbqueuetail(L, skb1) unixstateunlock(L) for u in gccandidates: if (u.inflight) scanchildren(u, incinflightmovetail)

                    // V count=1 inflight=2 (!)

If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCMRIGHTS. At this point, unixinflight() can not happen because unixgclock is already taken. Inflight graph remains unaffected.(CVE-2024-26923)

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:

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:

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:

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:

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

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:

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)

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

KVM: SVM: Flush pages under kvm->lock to fix UAF in svmregisterenc_region()

Do the cache flush of converted pages in svmregisterencregion() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has _unregisterencregion_locked() already queued up for the region.

Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed.

Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory.(CVE-2024-35791)

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:

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:

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:

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:

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)