OESA-2024-1737

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:

soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs

In brcmstbpmprobe(), there are two kinds of leak bugs:

(1) we need to add ofnodeput() when foreachmatchingnode() breaks (2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)

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:

pipe: wakeup wrwait after setting maxusage

Commit c73be61cede5 ("pipe: Add general notification queue support") a regression was introduced that would lock up resized pipes under certain conditions. See the reproducer in [1].

The commit resizing the pipe ring size was moved to a different function, doing that moved the wakeup for pipe->wrwait before actually raising pipe->maxusage. If a pipe was full before the resize occured it would result in the wakeup never actually triggering pipe_write.

Set @maxusage and @nraccounted before waking writers if this isn't a watch queue.

Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues

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

ACPI: video: check for error while searching for backlight device parent

If acpigetparent() called in acpivideodevregisterbacklight() fails, for example, because acpiutacquiremutex() fails inside acpigetparent), this can lead to incorrect (uninitialized) acpiparent handle being passed to acpigetpci_dev() for detecting the parent pci device.

Check acpigetparent() result and set parent device only in case of success.

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

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

mmc: mmcspi: fix error handling in mmcspi_probe()

If mmcaddhost() fails, it doesn't need to call mmcremovehost(), or it will cause null-ptr-deref, because of deleting a not added device in mmcremovehost().

To fix this, goto label 'failglueinit', if mmcaddhost() fails, and change the label 'failaddhost' to 'failgpiodrequest'.(CVE-2023-52708)

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

ceph: blocklist the kclient when receiving corrupted snap trace

When received corrupted snap trace we don't know what exactly has happened in MDS side. And we shouldn't continue IOs and metadatas access to MDS, which may corrupt or get incorrect contents.

This patch will just block all the further IO/MDS requests immediately and then evict the kclient itself.

The reason why we still need to evict the kclient just after blocking all the further IOs is that the MDS could revoke the caps faster.(CVE-2023-52732)

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

Fix page corruption caused by racy check in _freepages

When we upgraded our kernel, we started seeing some page corruption like the following consistently:

BUG: Bad page state in process ganesha.nfsd pfn:1304ca page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca flags: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000 raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x8664 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 Call Trace: dumpstack+0x74/0x96 badpage.cold+0x63/0x94 checknewpagebad+0x6d/0x80 rmqueue+0x46e/0x970 getpagefromfreelist+0xcb/0x3f0 ? _condresched+0x19/0x40 _allocpagesnodemask+0x164/0x300 allocpagescurrent+0x87/0xf0 skbpagefragrefill+0x84/0x110 ...

Sometimes, it would also show up as corruption in the free list pointer and cause crashes.

After bisecting the issue, we found the issue started from commit e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):

if (put_page_testzero(page))
    free_the_page(page, order);
else if (!PageHead(page))
    while (order-- > 0)
        free_the_page(page + (1 << order), order);

So the problem is the check PageHead is racy because at this point we already dropped our reference to the page. So even if we came in with compound page, the page can already be freed and PageHead can return false and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)

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

IB/hfi1: Restore allocated resources on failed copyout

Fix a resource leak if an error occurs.(CVE-2023-52747)

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

virtio-blk: fix implicit overflow on virtiomaxdma_size

The following codes have an implicit conversion from sizet to u32: (u32)maxsize = (sizet)virtiomaxdmasize(vdev);

This may lead overflow, Ex (sizet)4G -> (u32)0. Once virtiomaxdmasize() has a larger size than U32MAX, use U32MAX instead.(CVE-2023-52762)

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

fs/jfs: Add check for negative db_l2nbperpage

l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.

In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.

Syzbot reported this bug:

UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative(CVE-2023-52810)

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:

hsr: Prevent use after free in prpcreatetagged_frame()

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

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

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:

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

fs/aio: Check IOCBAIORW before the struct aio_kiocb conversion

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

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

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:

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:

netfilter: bridge: replace physindev with physinif in nfbridgeinfo

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

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

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

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

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

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:

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:

batman-adv: Avoid infinite loop trying to resize local TT

If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet.

But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of

batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)

in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more.

There are other scenarios possible with a similar result. The number of BATADVTTCLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes.

While this should be handled proactively when:

• interface with too low MTU is added
• VLAN is added
• non-purgeable local mac is added
• MTU of an attached interface is reduced
• fragmentation setting gets disabled (which most likely requires dropping attached interfaces)

not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.(CVE-2024-35982)

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:

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:

block: fix overflow in blkioctldiscard()

There is no check for overflow of 'start + len' in blkioctldiscard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.(CVE-2024-36917)

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:

s390/qeth: Fix kernel panic after setting hsuid

Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL.

Example:

[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: afiucv qethl3 zfcp scsitransportfc sunrpc nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftablesset nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables libcrc32c nfnetlink ghashs390 prng xts aess390 dess390 de sgeneric sha3512s390 sha3256s390 sha512s390 vfioccw vfiomdev mdev vfioiommutype1 eadmsch vfio ext4 mbcache jbd2 qethl2 bridge stp llc dasdeckdmod qeth dasdmod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stressclient Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] netrxaction+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] _dosoftirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] dosoftirqownstack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] dosoftirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] _localbhenableip+0x80/0x98 [ 2057.572825] [<0000000091314706>] _devqueuexmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucvhssend+0x24e/0x300 [afiucv] [ 2057.572830] [<000003ff803dd88a>] iucvsendctrl+0x102/0x138 [afiucv] [ 2057.572833] [<000003ff803de72a>] iucvsockconnect+0x37a/0x468 [afiucv] [ 2057.572835] [<00000000912e7e90>] _sysconnect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] syssocketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] systemcall+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] _napipoll+0x4c/0x1d8 [ 2057.572846]

[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt

Analysis: There is one napi structure per outq: card->qdio.outqs[i].napi The napi.poll functions are set during qeth_open().

Since commit 1cfef80d4c2b ("s390/qeth: Don't call devclose/devopen (DOWN/UP)") qethsetoffline()/qethsetonline() no longer call devclose()/ devopen(). So if qethfreeqdioqueues() cleared card->qdio.outqs[i].napi.poll while the network interface was UP and the card was offline, they are not set again.

Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated---(CVE-2024-36928)

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:

tipc: fix a possible memleak in tipcbufappend

_skblinearize() doesn't free the skb when it fails, so move '*buf = NULL' after _skblinearize(), so that the skb can be freed on the err path.(CVE-2024-36954)

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)