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

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.

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

wifi: libertas: fix some memleaks in lbsallocatecmdbuffer()

In the for statement of lbsallocatecmdbuffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbsallocatecmdbuffer().

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

dm snapshot: fix lockup in dmexceptiontableexit

The Linux kernel CVE team has assigned CVE-2024-35805 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051739-CVE-2024-35805-179f@gregkh/T

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

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtimeidle() callback and the .remove() callback in the rtsxpcr PCI driver leads to a kernel crash due to an unhandled page fault [1].

The problem is that rtsxpciruntimeidle() is not expected to be running after pmruntimegetsync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.

However, if a .runtimeidle() callback is already running when pmruntimegetsync() is called, the latter will notice that the runtime PM status of the device is RPMACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtimeidle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).

Thus in general, whoever is providing a .runtimeidle() callback needs to protect it from running in parallel with whatever code runs after pmruntimegetsync(). [Note that .runtimeidle() will not start after pmruntimegetsync() has returned, but it may continue running then if it has started earlier.]

One way to address that race condition is to call pmruntimebarrier() after pmruntimegetsync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtimeidle() callback to complete should it be running at that point. A suitable place for doing that is in pcideviceremove() which calls pmruntimegetsync() before removing the driver, so it may as well call pmruntimebarrier() subsequently, which will prevent the race in question from occurring, not just in the rtsxpcr driver, but in any PCI drivers providing .runtimeidle() callbacks.

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

ext4: fix corruption during on-line resize

The Linux kernel CVE team has assigned CVE-2024-35807 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051740-CVE-2024-35807-2a9e@gregkh/T

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

vfio/pci: Disable auto-enable of exclusive INTx IRQ

Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in requestirq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.

Instead, invert the logic using IRQFNOAUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.

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

ALSA: usb-audio: Stop parsing channels bits when all channels are found.

If a usb audio device sets more bits than the amount of channels it could write outside of the map array.

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

media: v4l2-mem2mem: fix a memleak in v4l2m2mregisterentity

The entity->name (i.e. name) is allocated in v4l2m2mregisterentity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.

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

media: v4l2-tpg: fix some memleaks in tpgalloc

In tpgalloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpgfree is called only when tpgalloc return 0.

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

media: imx: csc/scaler: fix v4l2ctrlhandler memory leak

Free the memory allocated in v4l2ctrlhandlerinit on release.

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

media: go7007: fix a memleak in go7007loadencoder

In go7007loadencoder, bounce(i.e. go->bootfw), is allocated without a deallocation thereafter. After the following call chain:

saa7134go7007init |-> go7007bootencoder |-> go7007loadencoder |-> kfree(go)

go is freed and thus bounce is leaked.

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

clk: Fix clkcoreget NULL dereference

It is possible for clkcoreget to dereference a NULL in the following sequence:

clkcoreget() ofclkgethwfromclkspec() ofclkgethwfromprovider() clkgethw()

clkgethw() can return NULL which is dereferenced by clkcoreget() at hw->core.

Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clklookups") the check ISERRORNULL() was performed which would have caught the NULL.

Reading the description of this function it talks about returning NULL but that cannot be so at the moment.

Update the function to check for hw before dereferencing it and return NULL if hw is NULL.

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

f2fs: fix to avoid potential panic during recovery

During recovery, if FAULTBLOCK is on, it is possible that f2fsreservenewblock() will return -ENOSPC during recovery, then it may trigger panic.

Also, if fault injection rate is 1 and only FAULTBLOCK fault type is on, it may encounter deadloop in loop of block reservation.

Let's change as below to fix these issues: - remove bugon() to avoid panic. - limit the loop count of block reservation to avoid potential deadloop.

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

net: phy: fix phygetinternaldelay accessing an empty array

The phygetinternaldelay function could try to access to an empty array in the case that the driver is calling phygetinternaldelay without defining delayvalues and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay = 0. As there is already delay < 0 test just before, the test could only be size == 0.

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

nbd: null check for nlaneststart

nlaneststart() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code.

fat: fix uninitialized field in nostale filehandles

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

drm/i915/gt: Reset queuepriorityhint on parking

Originally, with strict in order execution, we could complete execution only when the queue was empty. Preempt-to-busy allows replacement of an active request that may complete before the preemption is processed by HW. If that happens, the request is retired from the queue, but the queuepriorityhint remains set, preventing direct submission until after the next CS interrupt is processed.

This preempt-to-busy race can be triggered by the heartbeat, which will also act as the power-management barrier and upon completion allow us to idle the HW. We may process the completion of the heartbeat, and begin parking the engine before the CS event that restores the queuepriorityhint, causing us to fail the assertion that it is MIN.

<3>[ 166.210729] enginepark:283 GEMBUGON(engine->schedengine->queuepriorityhint != (-((int)(~0U >> 1)) - 1)) <0>[ 166.210781] Dumping ftrace buffer: <0>[ 166.210795] --------------------------------- ... <0>[ 167.302811] drmfdin-1097 2..s1. 165741070us : traceports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 } <0>[ 167.302861] drmfdin-1097 2d.s2. 165741072us : execlistssubmissiontasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646 <0>[ 167.302928] drmfdin-1097 2d.s2. 165741072us : i915requestunsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0 <0>[ 167.302992] drmfdin-1097 2d.s2. 165741073us : i915requestsubmit: 0000:00:02.0 rcs0: fence 3:4660, current 4659 <0>[ 167.303044] drmfdin-1097 2d.s1. 165741076us : execlistssubmissiontasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40 <0>[ 167.303095] drmfdin-1097 2d.s1. 165741077us : traceports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660 prio 2147483646 } <0>[ 167.303159] kworker/-89 11..... 165741139us : i915requestretire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2 <0>[ 167.303208] kworker/-89 11..... 165741148us : intelcontextdounpin: 0000:00:02.0 rcs0: context:c90 unpin <0>[ 167.303272] kworker/-89 11..... 165741159us : i915requestretire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2 <0>[ 167.303321] kworker/-89 11..... 165741166us : intelcontextdounpin: 0000:00:02.0 rcs0: context:1217 unpin <0>[ 167.303384] kworker/-89 11..... 165741170us : i915requestretire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660 <0>[ 167.303434] kworker/-89 11d..1. 165741172us : intelcontextretire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns } <0>[ 167.303484] kworker/-89 11..... 165741198us : enginepark: 0000:00:02.0 rcs0: parked <0>[ 167.303534] <idle>-0 5d.H3. 165741207us : execlistsirqhandler: 0000:00:02.0 rcs0: semaphore yield: 00000040 <0>[ 167.303583] kworker/-89 11..... 165741397us : intelcontextretire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns } <0>[ 167.303756] kworker/-89 11..... 165741777us : intelcontextretire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns } <0>[ 167.303806] kworker/-89 11..... 165742017us : enginepark: enginepark:283 GEMBUGON(engine->schedengine->queuepriorityhint != (-((int)(~0U >> 1)) - 1)) <0>[ 167.303811] --------------------------------- <4>[ 167.304722] ------------[ cut here ]------------ <2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intelenginepm.c:283! <4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CIDRM14193-gc655e0fd2804+ #1 <4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 <4>[ 167.304738] Workqueue: i915-unordered retireworkhandler [i915] <4>[ 16 ---truncated---

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

scsi: core: Fix unremoved procfs host directory regression

Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${procname} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsiprochostdirrm() on scsiremovehost(). But that led to a potential duplicate call to the hostdirrm() routine, since it's also called from scsihostdevrelease(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdirrm() call from devrelease().

But it happens that this proc directory is created on scsihostalloc(), and that function "pairs" with scsihostdevrelease(), while scsiremovehost() pairs with scsiaddhost(). In other words, it seems the reason for removing the proc directory on devrelease() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsiaddhost() didn't happen. And that pattern happens to exist in some error paths, for example.

Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usbstorprobe2(). By checking that path, we can see that the BadDevice label leads to a scsihostput() after a SCSI host allocation, but there's no call to scsiaddhost() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure):

usb-storage 4-1:87.51: USB Mass Storage device detected procdirentry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 procregister+0x347/0x4e0 fs/proc/generic.c:376

The proper fix seems to still call scsiprochostdirrm() on devrelease(), but guard that with the state check for SHOSTCREATED; there is even a comment in scsihostdevrelease() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}host(), like the usb-storage case.

This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.

dosysnametohandle(): use kzalloc() to fix kernel-infoleak

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

wifi: ath9k: delay all of ath9kwmieventtasklet() until init is complete

The ath9kwmieventtasklet() used in ath9khtc assumes that all the data structures have been fully initialised by the time it runs. However, because of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k driver initialisation is completed.

We already committed a partial fix for this in commit: 8b3046abc99e ("ath9khtc: fix NULL pointer dereference at ath9khtctxgetpacket()")

However, that commit only aborted the WMITXSTATUSEVENTID command in the event tasklet, pairing it with an "initialisation complete" bit in the TX struct. It seems syzbot managed to trigger the race for one of the other commands as well, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9khtcprobedevice() instead of inside ath9ktxinit()).

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

iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected

For those endpoint devices connect to system via hotplug capable ports, users could request a hot reset to the device by flapping device's link through setting the slot's link control register, as pciehpist() DLLSC interrupt sequence response, pciehp will unload the device driver and then power it off. thus cause an IOMMU device-TLB invalidation (Intel VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence target device to be sent and deadly loop to retry that request after ITE fault triggered in interrupt context.

That would cause following continuous hard lockup warning and system hang

[ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822623] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822623] RIP: 0010:qisubmitsync+0x2c0/0x490 [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) knlGS:0000000000000000 [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0 [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 4223.822628] PKRU: 55555554 [ 4223.822628] Call Trace: [ 4223.822628] qiflushdeviotlb+0xb1/0xd0 [ 4223.822628] dmarremoveonedevinfo+0x224/0x250 [ 4223.822629] dmarremoveonedevinfo+0x3e/0x50 [ 4223.822629] inteliommureleasedevice+0x1f/0x30 [ 4223.822629] iommureleasedevice+0x33/0x60 [ 4223.822629] iommubusnotifier+0x7f/0x90 [ 4223.822630] blockingnotifiercallchain+0x60/0x90 [ 4223.822630] devicedel+0x2e5/0x420 [ 4223.822630] pciremovebusdevice+0x70/0x110 [ 4223.822630] pciehpunconfiguredevice+0x7c/0x130 [ 4223.822631] pciehpdisableslot+0x6b/0x100 [ 4223.822631] pciehphandlepresenceorlinkchange+0xd8/0x320 [ 4223.822631] pciehpist+0x176/0x180 [ 4223.822631] ? irqfinalizeoneshot.part.50+0x110/0x110 [ 4223.822632] irqthreadfn+0x19/0x50 [ 4223.822632] irqthread+0x104/0x190 [ 4223.822632] ? irqforcedthreadfn+0x90/0x90 [ 4223.822632] ? irqthreadcheckaffinity+0xe0/0xe0 [ 4223.822633] kthread+0x114/0x130 [ 4223.822633] ? kthreadcancelwork+0x40/0x40 [ 4223.822633] retfromfork+0x1f/0x30 [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822634] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822634] Call Trace: [ 4223.822634] <NMI> [ 4223.822635] dumpstack+0x6d/0x88 [ 4223.822635] panic+0x101/0x2d0 [ 4223.822635] ? retfromfork+0x11/0x30 [ 4223.822635] nmipanic.cold.14+0xc/0xc [ 4223.822636] watchdogoverflowcallback.cold.8+0x6d/0x81 [ 4223.822636] perfeventoverflow+0x4f/0xf0 [ 4223.822636] handlepmicommon ---truncated---

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

Bluetooth: hcicore: Fix possible buffer overflow

struct hcidevinfo has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy.

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

ACPI: processoridle: Fix memory leak in acpiprocessorpowerexit()

After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak:

unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 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 (crc 8836a742): [<ffffffff993495ed>] kmalloctrace+0x29d/0x340 [<ffffffff9972f3b3>] acpiprocessorpowerinit+0xf3/0x1c0 [<ffffffff9972d263>] acpiprocessorstart+0xd3/0xf0 [<ffffffff9972d2bc>] acpiprocessorstart+0x2c/0x50 [<ffffffff99805872>] reallyprobe+0xe2/0x480 [<ffffffff99805c98>] driverprobedevice+0x78/0x160 [<ffffffff99805daf>] driverprobedevice+0x1f/0x90 [<ffffffff9980601e>] driverattach+0xce/0x1c0 [<ffffffff99803170>] busforeachdev+0x70/0xc0 [<ffffffff99804822>] busadddriver+0x112/0x210 [<ffffffff99807245>] driverregister+0x55/0x100 [<ffffffff9aee4acb>] acpiprocessordriverinit+0x3b/0xc0 [<ffffffff990012d1>] dooneinitcall+0x41/0x300 [<ffffffff9ae7c4b0>] kernelinitfreeable+0x320/0x470 [<ffffffff99b231f6>] kernelinit+0x16/0x1b0 [<ffffffff99042e6d>] retfromfork+0x2d/0x50

Fix this by freeing the CPU idle device after unregistering it.

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

quota: Fix potential NULL pointer dereference

Below race may cause NULL pointer dereference

P1 P2 dquotfreeinode quotaoff dropdquotref removedquotref dquots = idquot(inode) dquots = idquot(inode) srcureadlock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spinlock(&dquots[cnt]->dqdqblock) (3) ....

If dquotfreeinode(or other routines) checks inode's quota pointers (1) before quotaoff sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered.

So let's fix it by using a temporary pointer to avoid this issue.

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

media: pvrusb2: fix uaf in pvr2contextsetnotify

[Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26

CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usbhubwq hubevent Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2contextnotify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2contextdisconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272

Freed by task 906: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] kasanslabfree+0x106/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inline] slabfree mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2contextcheck drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2contextthreadfunc+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158

[Analyze] Task A set disconnectflag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue.

[Fix] Place the disconnectflag assignment operation after all code in pvr2contextdisconnect() to avoid this issue.

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

net/bnx2x: Prevent access to a freed page in pagepool

Fix race condition leading to system crash during EEH error handling

During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2xtxtimeout() schedules reset tasks via bnx2xsprtnltask(), which ultimately leads to bnx2xnicunload(). In bnx2xnicunload() SGEs are freed using bnx2xfreerxsgerange(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2xioslotreset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2xfreerxsge()

799 static inline void bnx2xfreerxsge(struct bnx2x bp, 800 struct bnx2xfastpath fp, u16 index) 801 { 802 struct swrxpage swbuf = &fp->rxpagering[index]; 803 struct page page = swbuf->page; .... where swbuf was set to NULL after the call to dmaunmappage() by the preceding thread.

EEH: Beginning: 'slotreset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slotreset() bnx2x: [bnx2xioslotreset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2xioslotreset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2xioslotreset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eehreportreset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eehpereport+0x180/0x550 [c000000003c67c70] [c00000000005318c] eehhandlenormalevent+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeheventhandler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] retfromkernelthread+0x5c/0x64

To solve this issue, we need to verify page pool allocations before freeing.

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

hsr: Fix uninit-value access in hsrgetnode()

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

===================================================== BUG: KMSAN: uninit-value in hsrgetnode+0xa2e/0xa40 net/hsr/hsrframereg.c:246 hsrgetnode+0xa2e/0xa40 net/hsr/hsrframereg.c:246 fillframeinfo net/hsr/hsrforward.c:577 [inline] hsrforwardskb+0xe12/0x30e0 net/hsr/hsrforward.c:615 hsrdevxmit+0x1a1/0x270 net/hsr/hsrdevice.c:223 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3087 [inline] packetsendmsg+0x8b1d/0x9f30 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendto+0x735/0xa10 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2787 packetallocskb net/packet/afpacket.c:2936 [inline] packetsnd net/packet/afpacket.c:3030 [inline] packetsendmsg+0x70e8/0x9f30 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendto+0x735/0xa10 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x6d/0x140 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================

If the packet type ID field in the Ethernet header is either ETHPPRP or ETHPHSR, but it is not followed by an HSR tag, hsrgetskbsequencenr() reads an invalid value as a sequence number. This causes the above issue.

This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.

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

wireguard: receive: annotate data-race around receivingcounter.counter

Syzkaller with KCSAN identified a data-race issue when accessing keypair->receivingcounter.counter. Use READONCE() and WRITEONCE() annotations to mark the data race as intentional.

BUG: KCSAN: data-race in wgpacketdecryptworker / wgpacketrxpoll

write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: countervalidate drivers/net/wireguard/receive.c:321 [inline] wgpacketrxpoll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 napipoll+0x60/0x3b0 net/core/dev.c:6536 napipoll net/core/dev.c:6605 [inline] netrxaction+0x32b/0x750 net/core/dev.c:6738 dosoftirq+0xc4/0x279 kernel/softirq.c:553 dosoftirq+0x5e/0x90 kernel/softirq.c:454 localbhenableip+0x64/0x70 kernel/softirq.c:381 rawspinunlockbh include/linux/spinlockapismp.h:167 [inline] rawspinunlockbh+0x36/0x40 kernel/locking/spinlock.c:210 spinunlockbh include/linux/spinlock.h:396 [inline] ptrringconsumebh include/linux/ptrring.h:367 [inline] wgpacketdecryptworker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 processonework kernel/workqueue.c:2633 [inline] ...

read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decryptpacket drivers/net/wireguard/receive.c:252 [inline] wgpacketdecryptworker+0x220/0x700 drivers/net/wireguard/receive.c:501 processonework kernel/workqueue.c:2633 [inline] processscheduledworks+0x5b8/0xa30 kernel/workqueue.c:2706 workerthread+0x525/0x730 kernel/workqueue.c:2787 ...

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

x86, relocs: Ignore relocations in .notes section

When building with CONFIGXENPV=y, .text symbols are emitted into the .notes section so that Xen can find the "startupxen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable.

To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map.

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

sr9800: Add check for usbnetgetendpoints

Add check for usbnetgetendpoints() and return the error if it fails in order to transfer the error.