OESA-2024-1738

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server

AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value.

This is a problem, however, since the file position and length fields of FS.FetchData are signed 32-bit values.

Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICEDCAPABILITY64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper32bits() to switch on the parameter values.

This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that.

Note that the issue does not exist with FS.StoreData - that uses unsigned 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values.

This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client[1]. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like:

error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index

This can be observed in the server's FileLog with something like the following appearing:

Sun Aug 29 19:31:39 2021 SRXAFSFetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchDataRXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchDataRXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFSFetchData returns 5

Note the file position of 18446744071815340032. This is the requested file position sign-extended.(CVE-2021-47366)

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

net/smc: Fix possible access to freed memory in link clear

After modifying the QP to the Error state, all RX WR would be completed with WC in IBWCWRFLUSHERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context.

Here is a crash example:

BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:nativequeuedspinlockslowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _rawspinlockirqsave+0x30/0x40 mlx5ibpollcq+0x4c/0xc50 [mlx5ib] smcwrrxtaskletfn+0x56/0xa0 [smc] taskletactioncommon.isra.21+0x66/0x100 _dosoftirq+0xd5/0x29c asmcallirqonstack+0x12/0x20 </IRQ> dosoftirqownstack+0x37/0x40 irqexitrcu+0x9d/0xa0 sysveccallfunctionsingle+0x34/0x80 asmsysveccallfunctionsingle+0x12/0x20(CVE-2022-48673)

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

RDMA/srp: Set scmnd->result only when scmnd is not NULL

This change fixes the following kernel NULL pointer dereference which is reproduced by blktests srp/007 occasionally.

BUG: kernel NULL pointer dereference, address: 0000000000000170 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014 Workqueue: 0x0 (kblockd) RIP: 0010:srprecvdone+0x176/0x500 [ibsrp] Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9 RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000 RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001 R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000 R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0 Call Trace: <IRQ> _ibprocesscq+0xb7/0x280 [ibcore] ibpollhandler+0x2b/0x130 [ibcore] irqpollsoftirq+0x93/0x150 _dosoftirq+0xee/0x4b8 irqexitrcu+0xf7/0x130 sysvecapictimer_interrupt+0x8e/0xc0 </IRQ>(CVE-2022-48692)

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

rpmsg: virtio: Free driveroverride when rpmsgremove()

Free driveroverride when rpmsgremove(), otherwise the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsgns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] _kmemcacheallocnode+0x1f8/0x320 [<000000002300d89b>] _kmallocnodetrackcaller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driversetoverride+0xd0/0x164 [<000000003e9c4ea5>] rpmsgregisterdeviceoverride+0x98/0x170 [<000000001c0c89a8>] rpmsgnsregisterdevice+0x24/0x30 [<000000008bbf8fa2>] rpmsgprobe+0x2e0/0x3ec [<00000000e65a68df>] virtiodevprobe+0x1c0/0x280 [<00000000443331cc>] reallyprobe+0xbc/0x2dc [<00000000391064b1>] _driverprobedevice+0x78/0xe0 [<00000000a41c9a5b>] driverprobedevice+0xd8/0x160 [<000000009c3bd5df>] _deviceattachdriver+0xb8/0x140 [<0000000043cd7614>] busforeachdrv+0x7c/0xd4 [<000000003b929a36>] _deviceattach+0x9c/0x19c [<00000000a94e0ba8>] deviceinitialprobe+0x14/0x20 [<000000003c999637>] busprobedevice+0xa0/0xac(CVE-2023-52670)

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

f2fs: avoid format-overflow warning

With gcc and W=1 option, there's a warning like this:

fs/f2fs/compress.c: In function ‘f2fsinitpagearraycache’: fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between 1 and 7 bytes into a region of size between 5 and 8 [-Werror=format-overflow=] 1984 | sprintf(slabname, "f2fspagearrayentry-%u:%u", MAJOR(dev), MINOR(dev)); | ^~

String "f2fspagearrayentry-%u:%u" can up to 35. The first "%u" can up to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35". slabname's size should be 35 rather than 32.(CVE-2023-52748)

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

i2c: core: Run atomic i2c xfer when !preemptible

Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in waitforcompletion() while waiting for the DMA).

panic() calls preemptdisablenotrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like:

[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/treeplugin.h:318 rcunotecontextswitch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] scheduletimeout from waitforcompletiontimeout+0x90/0x114 [ 12.749179] waitforcompletiontimeout from tegrai2cwaitcompletion+0x40/0x70 ... [ 12.994527] atomicnotifiercallchain from machinerestart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c

Use !preemptible() instead, which is basically the same check as pre-v5.2.(CVE-2023-52791)

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

drm/panel: fix a possible null pointer dereference

In versatilepanelgetmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drmmode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)

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

media: vidtv: mux: Add check and kfree for kstrdup

Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak.(CVE-2023-52841)

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

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

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

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

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change

While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.(CVE-2023-52882)

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

netfilter: nftsetpipapo: do not free live element

Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo:

addelem("00000000") timeout 100 ms ... addelem("0000000X") timeout 100 ms delelem("0000000X") <---------------- delete one that was just added ... addelem("00005000") timeout 100 ms

1) nftpipaporemove() removes element 0000000X Then, KASAN shows a splat.

Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element.

Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map.

The _remove function does not work correctly if we have more than one element that share the same key.

This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation.

In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable.

The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer).

Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching.

Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element.

v2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)

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 proc_register+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.(CVE-2024-26935)

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

ksmbd: validate request buffer size in smb2allocatersp_buf()

The response buffer should be allocated in smb2allocaterspbuf before validating request. But the fields in payload as well as smb2 header is used in smb2allocaterspbuf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)

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

ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses

Since commit a4d5613c4dc6 ("arm: extend pfnvalid to take into account freed memory map alignment") changes the semantics of pfnvalid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout:

node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000

the crash backtrace like:

Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15flushkerndcachearea+0x24/0x3c LR is at syncicachedcache+0x6c/0x98 [...] (b15flushkerndcachearea) from (syncicachedcache+0x6c/0x98) (syncicachedcache) from (setpteat+0x28/0x54) (setpteat) from (remappfnrange+0x1a0/0x274) (remappfnrange) from (uiommap+0x184/0x1b8 [uio]) (uiommap [uio]) from (mmapregion+0x264/0x5f4) (mmapregion) from (dommapmm+0x3ec/0x440) (_dommapmm) from (dommap+0x50/0x58) (dommap) from (vmmmappgoff+0xfc/0x188) (vmmmappgoff) from (ksysmmappgoff+0xac/0xc4) (ksysmmappgoff) from (retfast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception

So check if PG_reserved was set to solve this issue.

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

ksmbd: fix slab-out-of-bounds in smbstrndupfrom_utf16()

If ->NameOffset of smb2createreq is smaller than Buffer offset of smb2createreq, slab-out-of-bounds read can happen from smb2open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2create_req().(CVE-2024-26954)

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

mm: swap: fix race between freeswapand_cache() and swapoff()

There was previously a theoretical window where swapoff() could run and teardown a swapinfostruct while a call to freeswapandcache() was running in another thread. This could cause, amongst other bad possibilities, swappagetranshugeswapped() (called by freeswapandcache()) to access the freed memory for swap_map.

This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below).

Fix it by using getswapdevice()/putswapdevice(), which will stall swapoff(). There was an extra check in swapinfoget() to confirm that the swap entry was not free. This isn't present in getswapdevice() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in freeswapandcache().

Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this):

--8<-----

_swapentryfree() might be the last user and result in "count == SWAPHAS_CACHE".

swapoff->trytounuse() will stop as soon as soon as si->inuse_pages==0.

So the question is: could someone reclaim the folio and turn si->inusepages==0, before we completed swappagetranshuge_swapped().

Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries.

Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry.

Process 1 quits. Calls freeswapandcache(). -> count == SWAPHAS_CACHE [then, preempted in the hypervisor etc.]

Process 2 quits. Calls freeswapandcache(). -> count == SWAPHAS_CACHE

Process 2 goes ahead, passes swappagetranshugeswapped(), and calls _trytoreclaimswap().

_trytoreclaimswap()->foliofreeswap()->deletefromswapcache()-> putswapfolio()->freeswapslot()->swapcachefreeentries()-> swapentryfree()->swaprangefree()-> ... WRITEONCE(si->inusepages, si->inusepages - nr_entries);

What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swappagetranshugeswapped()?

--8<-----(CVE-2024-26960)

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

net/mlx5e: Prevent deadlock while disabling aRFS

When disabling aRFS under the priv->state_lock, any scheduled aRFS works are canceled using the cancel_work_sync function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the state_lock which is already acquired.

The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.

Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.

Kernel log:

====================================================== WARNING: possible circular locking dependency detected

6.7.0-rc4netnextmlx55483eb2 #1 Tainted: G I

ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((workcompletion)(&rule->arfswork)){+.+.}-{0:0}, at: _flushwork+0x74/0x4e0

but task is already holding lock: ffff8884a1808cc0 (&priv->statelock){+.+.}-{3:3}, at: mlx5eethtoolsetchannels+0x53/0x200 [mlx5_core]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&priv->statelock){+.+.}-{3:3}: _mutexlock+0x80/0xc90 arfshandlework+0x4b/0x3b0 [mlx5core] processonework+0x1dc/0x4a0 workerthread+0x1bf/0x3c0 kthread+0xd7/0x100 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20

-> #0 ((workcompletion)(&rule->arfswork)){+.+.}-{0:0}: _lockacquire+0x17b4/0x2c80 lockacquire+0xd0/0x2b0 _flushwork+0x7a/0x4e0 _cancelworktimer+0x131/0x1c0 arfsdelrules+0x143/0x1e0 [mlx5core] mlx5earfsdisable+0x1b/0x30 [mlx5core] mlx5eethtoolsetchannels+0xcb/0x200 [mlx5core] ethnlsetchannels+0x28f/0x3b0 ethnldefaultsetdoit+0xec/0x240 genlfamilyrcvmsgdoit+0xd0/0x120 genlrcvmsg+0x188/0x2c0 netlinkrcvskb+0x54/0x100 genlrcv+0x24/0x40 netlinkunicast+0x1a1/0x270 netlinksendmsg+0x214/0x460 _socksendmsg+0x38/0x60 _syssendto+0x113/0x170 _x64syssendto+0x20/0x30 dosyscall64+0x40/0xe0 entrySYSCALL64after_hwframe+0x46/0x4e

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(&priv->statelock); lock((workcompletion)(&rule->arfswork)); lock(&priv->statelock); lock((workcompletion)(&rule->arfswork));

* DEADLOCK *

3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cblock){++++}-{3:3}, at: genlrcv+0x15/0x40 #1: ffffffff82e94c88 (rtnlmutex){+.+.}-{3:3}, at: ethnldefaultsetdoit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->statelock){+.+.}-{3:3}, at: mlx5eethtoolsetchannels+0x53/0x200 [mlx5_core]

stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4netnextmlx55483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x60/0xa0 checknoncircular+0x144/0x160 _lockacquire+0x17b4/0x2c80 lockacquire+0xd0/0x2b0 ? _flushwork+0x74/0x4e0 ? savetrace+0x3e/0x360 ? _flushwork+0x74/0x4e0 _flushwork+0x7a/0x4e0 ? _flushwork+0x74/0x4e0 ? _lockacquire+0xa78/0x2c80 ? lockacquire+0xd0/0x2b0 ? markheldlocks+0x49/0x70 _cancelworktimer+0x131/0x1c0 ? markheldlocks+0x49/0x70 arfsdelrules+0x143/0x1e0 [mlx5core] mlx5earfsdisable+0x1b/0x30 [mlx5core] mlx5eethtoolsetchannels+0xcb/0x200 [mlx5core] ethnlsetchannels+0x28f/0x3b0 ethnldefaultsetdoit+0xec/0x240 genlfamilyrcvmsgdoit+0xd0/0x120 genlrcvmsg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)

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

netfilter: nftsetpipapo: walk over current view on netlink dump

The generation mask can be updated while netlink dump is in progress. The pipapo set backend walk iterator cannot rely on it to infer what view of the datastructure is to be used. Add notation to specify if user wants to read/update the set.

Based on patch from Florian Westphal.(CVE-2024-27017)

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

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

nftunregisterobj() can concurrent with _nftobjtypeget(), and there is not any protection when iterate over nftablesobjects list in _nftobjtypeget(). Therefore, there is potential data-race of nftablesobjects list entry.

Use listforeachentryrcu() to iterate over nftablesobjects list in _nftobjtypeget(), and use rcureadlock() in the caller nftobjtype_get() to protect the entire type query process.(CVE-2024-27019)

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

drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10setoutputtransferfunc()'

The 'stream' pointer is used in dcn10setoutputtransferfunc() before the check if 'stream' is NULL.

Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10hwseq.c:1892 dcn10setoutputtransfer_func() warn: variable dereferenced before check 'stream' (see line 1875)(CVE-2024-27044)

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

net: lltemac: platformget_resource replaced by wrong function

The function platformgetresource was replaced with devmplatformioremapresourcebyname and is called using 0 as name.

This eventually ends up in platformgetresource_byname in the call stack, where it causes a null pointer in strcmp.

if (type == resource_type(r) && !strcmp(r->name, name))

It should have been replaced with devmplatformioremap_resource.(CVE-2024-35796)

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

soc: fsl: qbman: Use raw spinlock for cgr_lock

smpcallfunction always runs its callback in hard IRQ context, even on PREEMPTRT, where spinlocks can sleep. So we need to use a raw spinlock for cgrlock to ensure we aren't waiting on a sleeping task.

Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smpcallfunctionsingle via qmanupdatecgrsafe every time a link goes up or down.(CVE-2024-35819)

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

ubifs: Set page uptodate in the correct place

Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifswriteend(), which is after we copied the new data into the page.(CVE-2024-35821)

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

wifi: libertas: fix some memleaks in lbsallocatecmd_buffer()

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().(CVE-2024-35828)

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

smb: client: fix UAF in smb2reconnectserver()

The UAF bug is due to smb2reconnectserver() accessing a session that is already being teared down by another thread that is executing _cifsputsmbses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->sesstatus again to something different than SESEXITING.

To fix this, we need to make sure to unconditionally set @ses->sesstatus to SESEXITING and prevent any other threads from setting a new status while we're still tearing it down.

The following can be reproduced by adding some delay to right after the ipc is freed in _cifsputsmbses() - which will give smb2reconnectserver() worker a chance to run and then accessing @ses->ipc:

kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echointerval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2reconnectserver [cifs] RIP: 0010:listdelentryvalidorreport+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? dieaddr+0x36/0x90 ? excgeneralprotection+0x1c1/0x3f0 ? asmexcgeneralprotection+0x26/0x30 ? _listdelentryvalidorreport+0x33/0xf0 _cifsputsmbses+0x1ae/0x500 [cifs] smb2reconnectserver+0x4ed/0x710 [cifs] processonework+0x205/0x6b0 workerthread+0x191/0x360 ? _pfxworkerthread+0x10/0x10 kthread+0xe2/0x110 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>(CVE-2024-35870)

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

ax25: fix use-after-free bugs caused by ax25dsdel_timer

When the ax25 device is detaching, the ax25devdevicedown() calls ax25dsdeltimer() to cleanup the slavetimer. When the timer handler is running, the ax25dsdeltimer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below:

  (Thread 1)          |      (Thread 2)
                      | ax25_ds_timeout()

ax25devdevicedown() | ax25dsdeltimer() | deltimer() | ax25devput() //FREE | | ax25dev-> //USE

In order to mitigate bugs, when the device is detaching, use timershutdownsync() to stop the timer.(CVE-2024-35887)

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

tcp: properly terminate timers for kernel sockets

We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.

Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.

When TCP sockets are closed, we call inetcskclearxmittimers() to 'stop' the timers.

inetcskclearxmittimers() can be called from any context, including when socket lock is held. This is the reason it uses skstoptimer(), aka del_timer(). This means that ongoing timers might finish much later.

For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.

For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.

This patch adds inetcskclearxmittimerssync() function that using skstoptimersync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.

Also add socknotownedbyme() helper to get LOCKDEP support : inetcskclearxmittimers_sync() must not be called while socket lock is held.

It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)

We probably can remove the checknet() tests from tcpoutofresources() and _tcpclose() in the future.(CVE-2024-35910)

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

nfc: nci: Fix uninit-value in ncidevup and ncintfpacket

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

ncirxwork() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.

This patch resolved this issue by checking payload size before calling each message type handler codes.(CVE-2024-35915)

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

drm/vc4: don't check if plane->state->fb == state->fb

Currently, when using non-blocking commits, we can see the following kernel warning:

[ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcountt: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcountdecnotone+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm sndseqdummy sndhrtimer sndseq sndseqdevice cmac algifhash aesarm64 aesgeneric algifskcipher afalg bnep hidlogitechhidpp vc4 brcmfmac hciuart btbcm brcmutil bluetooth sndsochdmicodec cfg80211 cec drmdisplayhelper drmdmahelper drmkmshelper sndsoccore sndcompress sndpcmdmaengine fbsysfops sysimgblt syscopyarea sysfillrect raspberrypihwmon ecdhgeneric ecc rfkill libaes i2cbcm2835 binfmtmisc joydev sndbcm2835(C) bcm2835codec(C) bcm2835isp(C) v4l2mem2mem videobuf2dmacontig sndpcm bcm2835v4l2(C) raspberrypigpiomem bcm2835mmalvchiq(C) videobuf2v4l2 sndtimer videobuf2vmalloc videobuf2memops videobuf2common snd videodev vcsmcma(C) mc hidlogitechdj uiopdrvgenirq uio i2cdev drm fuse dmmod drmpanelorientationquirks backlight iptables xtables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcountdecnotone+0xb8/0xc0 [ 110.909152] lr : refcountdecnotone+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcountdecnotone+0xb8/0xc0 [ 110.909461] vc4bodecusecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4cleanupfb+0x44/0x50 [vc4] [ 110.910315] drmatomichelpercleanupplanes+0x88/0xa4 [drmkmshelper] [ 110.910669] vc4atomiccommittail+0x390/0x9dc [vc4] [ 110.911079] committail+0xb0/0x164 [drmkmshelper] [ 110.911397] drmatomichelpercommit+0x1d0/0x1f0 [drmkmshelper] [ 110.911716] drmatomiccommit+0xb0/0xdc [drm] [ 110.912569] drmmodeatomicioctl+0x348/0x4b8 [drm] [ 110.913330] drmioctlkernel+0xec/0x15c [drm] [ 110.914091] drmioctl+0x24c/0x3b0 [drm] [ 110.914850] _arm64sysioctl+0x9c/0xd4 [ 110.914873] invokesyscall+0x4c/0x114 [ 110.914897] el0svccommon+0xd0/0x118 [ 110.914917] doel0svc+0x38/0xd0 [ 110.914936] el0svc+0x30/0x8c [ 110.914958] el0t64synchandler+0x84/0xf0 [ 110.914979] el0t64sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]---

This happens because, although prepare_fb and cleanup_fb are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in prepare_fb and don't decrease it in cleanup_fb. The opposite can also be true.

In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the drm_atomic_get_new_plane_state() helper function should be used. So, we could stick to this check, but using drm_atomic_get_new_plane_state(). But actually, this check is not re ---truncated---(CVE-2024-35932)

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

btrfs: send: handle path ref underflow in header iterateinoderef()

Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)

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

wifi: cfg80211: check A-MSDU format more carefully

If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)

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

drm/panfrost: Fix the error path in panfrostmmumapfaultaddr()

Subject: [PATCH] drm/panfrost: Fix the error path in panfrostmmumapfaultaddr()

If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.(CVE-2024-35951)

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

Bluetooth: L2CAP: Fix not validating setsockopt user input

Check user input length before copying data.(CVE-2024-35965)

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

Bluetooth: RFCOMM: Fix not validating setsockopt user input

syzbot reported rfcommsocksetsockopt_old() is copying data without checking user input length.

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 rfcommsocksetsockoptold net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcommsocksetsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)

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

tty: ngsm: fix possible out-of-bounds in gsm0receive()

Assuming the following: - side A configures the ngsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.

Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAXMRU in gsm0receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.

All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)

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

tcp: defer shutdown(SENDSHUTDOWN) for TCPSYN_RECV sockets

TCPSYNRECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide by zero in tcprcvspace_adjust()

A socket makes the following state transitions, without ever calling tcpinittransfer(), meaning tcpinitbuffer_space() is also not called.

     TCP_CLOSE

connect() TCPSYNSENT TCPSYNRECV shutdown() -> tcpshutdown(sk, SENDSHUTDOWN) TCPFINWAIT1

To fix this issue, change tcpshutdown() to not perform a TCPSYNRECV -> TCPFIN_WAIT1 transition, which makes no sense anyway.

When tcprcvstateprocess() later changes socket state from TCPSYNRECV to TCPESTABLISH, then look at sk->skshutdown to finally enter TCPFIN_WAIT1 state, and send a FIN packet from a sane socket state.

This means tcpsendfin() can now be called from BH context, and must use GFP_ATOMIC allocations.

[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcprcvspaceadjust+0x2df/0x890 net/ipv4/tcpinput.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcprecvmsglocked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcprecvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6recvmsg+0x16a/0x730 net/ipv6/afinet6.c:680 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 sysrecvmsg net/socket.c:2845 [inline] dorecvmmsg+0x474/0xae0 net/socket.c:2939 _sysrecvmmsg net/socket.c:3018 [inline] _dosysrecvmmsg net/socket.c:3041 [inline] _sesysrecvmmsg net/socket.c:3034 [inline] _x64sysrecvmmsg+0x199/0x250 net/socket.c:3034 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)

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

blk-iocost: avoid out of bounds shift

UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.

[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0fbk700debugrc2kbuilder0gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F093A23 12/08/2020 Call Trace: <IRQ> dumpstacklvl+0x8f/0xe0 _ubsanhandleshiftoutofbounds+0x22c/0x280 iocgkickdelay+0x30b/0x310 ioctimerfn+0x2fb/0x1f80 _runtimerbase+0x1b6/0x250 ...

Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.

I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.(CVE-2024-36916)

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

scsi: bnx2fc: Remove spinlockbh while releasing resources after upload

The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.

This will suppress following BUG_ON():

[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x8664 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fcrporteq fcrportwork [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] _iommudmafree+0x96/0x100 [ 450.000139] bnx2fcfreesessionresc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fcuploadsession+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fcrporteventhandler+0x9f/0x240 [bnx2fc] [ 450.018136] fcrportwork+0x103/0x5b0 [libfc] [ 450.023103] processonework+0x1e8/0x3c0 [ 450.027581] workerthread+0x50/0x3b0 [ 450.031669] ? rescuerthread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? setkthreadstruct+0x40/0x40 [ 450.044411] retfromfork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfslayoutnfsv41files rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver dmservicetime qedf qed crc8 bnx2fc libfcoe libfc scsitransportfc intelraplmsr intelraplcommon x86pkgtempthermal intelpowerclamp dcdbas rapl intelcstate inteluncore meime pcspkr mei ipmissif lpcich ipmisi fuse zram ext4 mbcache jbd2 loop nfsv3 nfsacl nfs lockd grace fscache netfs irdma ice sdmod t10pi sg ibuverbs ibcore 8021q garp mrp stp llc mgag200 i2calgobit drmkmshelper syscopyarea sysfillrect sysimgblt mxmwmi fbsysfops cec crct10difpclmul ahci crc32pclmul bnx2x drm ghashclmulniintel libahci rfkill i40e libata megaraidsas mdio wmi sunrpc lrw dmcrypt dmroundrobin dmmultipath dmsnapshot dmbufio dmmirror dmregionhash dmlog dmzero dmmod linear raid10 raid456 asyncraid6recov asyncmemcpy asyncpq asyncxor asynctx raid6pq libcrc32c crc32cintel raid1 raid0 iscsiibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsibootsysfs iscsitcp libiscsitcp libiscsi scsitransportiscsi edd ipmidevintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)

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

scsi: lpfc: Move NPIV's transport unregistration to after resource clean up

There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.

Currently fcremovehost(), which calls devlosstmo for all DIDs including the fabric DID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.

Fix by moving the fcremovehost() and scsiremovehost() calls after DA_ID and LOGO are sent.(CVE-2024-36952)

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

drm/vmwgfx: Fix invalid reads in fence signaled events

Correctly set the length of the drm_event to the size of the structure that's actually used.

The length of the drmevent was set to the parent structure instead of to the drmvmweventfence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)

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

Bluetooth: L2CAP: Fix div-by-zero in l2capleflowctl_init()

l2capleflowctlinit() can cause both div-by-zero and an integer overflow since hdev->lemtu may not fall in the valid range.

Move MTU from hcidev to hciconn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in readbuffersize() and make it return an error value if the validation fails. Now hciconnadd() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value.

divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hcirxwork RIP: 0010:l2capleflowctlinit+0x19e/0x3f0 net/bluetooth/l2capcore.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2capleconnectreq net/bluetooth/l2capcore.c:4902 [inline] l2caplesigcmd net/bluetooth/l2capcore.c:5420 [inline] l2caplesigchannel net/bluetooth/l2capcore.c:5486 [inline] l2caprecvframe+0xe59d/0x11710 net/bluetooth/l2capcore.c:6809 l2caprecvacldata+0x544/0x10a0 net/bluetooth/l2capcore.c:7506 hciacldatapacket net/bluetooth/hcicore.c:3939 [inline] hcirxwork+0x5e5/0xb20 net/bluetooth/hcicore.c:4176 processonework kernel/workqueue.c:3254 [inline] processscheduledworks+0x90f/0x1530 kernel/workqueue.c:3335 workerthread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 retfromfork+0x5c/0x90 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---(CVE-2024-36968)

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

net: fix _dstnegative_advice() race

_dstnegativeadvice() does not enforce proper RCU rules when sk->dstcache must be cleared, leading to possible UAF.

RCU rules are that we must first clear sk->skdstcache, then call dstrelease(olddst).

Note that skdstreset(sk) is implementing this protocol correctly, while _dstnegative_advice() uses the wrong order.

Given that ip6negativeadvice() has special logic against RTFCACHE, this means each of the three ->negativeadvice() existing methods must perform the skdstreset() themselves.

Note the check against NULL dst is centralized in _dstnegative_advice(), there is no need to duplicate it in various callbacks.

Many thanks to Clement Lecigne for tracking this issue.

This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)