The Linux Kernel, the operating system core itself.

Security Fix(es):

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

bna: ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdupusernul instead of memdup_user.(CVE-2024-36934)

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

nilfs2: fix potential kernel bug due to lack of writeback flag waiting

Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (_foliostart_writeback in the log below):

kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:_foliostartwriteback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: <TASK> nilfssegctordoconstruct+0x4654/0x69d0 [nilfs2] nilfssegctorconstruct+0x181/0x6b0 [nilfs2] nilfssegctorthread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 retfromfork+0x4b/0x80 retfromfork_asm+0x1a/0x30 </TASK>

This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state.

Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state.(CVE-2024-37078)

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

xfrm6: check ip6dstidev() return value in xfrm6getsaddr()

ip6dstidev() can return NULL, xfrm6getsaddr() must act accordingly.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wgpackethandshakesendworker RIP: 0010:xfrm6getsaddr+0x93/0x130 net/ipv6/xfrm6policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xfrmgetsaddr net/xfrm/xfrmpolicy.c:2452 [inline] xfrmtmplresolveone net/xfrm/xfrmpolicy.c:2481 [inline] xfrmtmplresolve+0xa26/0xf10 net/xfrm/xfrmpolicy.c:2541 xfrmresolveandcreatebundle+0x140/0x2570 net/xfrm/xfrmpolicy.c:2835 xfrmbundlelookup net/xfrm/xfrmpolicy.c:3070 [inline] xfrmlookupwithifid+0x4d1/0x1e60 net/xfrm/xfrmpolicy.c:3201 xfrmlookup net/xfrm/xfrmpolicy.c:3298 [inline] xfrmlookuproute+0x3b/0x200 net/xfrm/xfrmpolicy.c:3309 ip6dstlookupflow+0x15c/0x1d0 net/ipv6/ip6output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wgsocketsendskbtopeer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wgsocketsendbuffertopeer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wgpacketsendhandshakeinitiation+0x227/0x360 drivers/net/wireguard/send.c:40 wgpackethandshakesendworker+0x1c/0x30 drivers/net/wireguard/send.c:51 processonework+0x9fb/0x1b60 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-40959)

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

drm/lima: mask irqs in timeout path before hard reset

There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on limapmidle, with a stack dump such as:

[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/limadevfreq.c:205 limadevfreqrecordidle+0xa0/0xb0 ... [10136.669459] pc : limadevfreqrecordidle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] limadevfreqrecordidle+0xa0/0xb0 [10136.669646] limaschedpipetaskdone+0x5c/0xb0 [10136.669656] limagpirqhandler+0xa8/0x120 [10136.669666] _handleirqeventpercpu+0x48/0x160 [10136.669679] handleirq_event+0x4c/0xc0

We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler.(CVE-2024-40976)

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

scsi: qedi: Fix crash while reading debugfs attribute

The qedidbgdonotrecovercmdread() function invokes sprintf() directly on a __user pointer, which results into the crash.

To fix this issue, use a small local stack buffer for sprintf() and then call simplereadfrombuffer(), which in turns make the copyto_user() call.

BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpyorig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? _diebody+0x1a/0x60 ? pagefaultoops+0x183/0x510 ? excpagefault+0x69/0x150 ? asmexcpagefault+0x22/0x30 ? memcpyorig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedidbgdonotrecovercmdread+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] fullproxyread+0x50/0x80 vfsread+0xa5/0x2e0 ? folioaddnewanonrmap+0x44/0xa0 ? setpteat+0x15/0x30 ? doptemissing+0x426/0x7f0 ksysread+0xa5/0xe0 dosyscall64+0x58/0x80 ? _countmemcgevents+0x46/0x90 ? countmemcgeventmm+0x3d/0x60 ? handlemmfault+0x196/0x2f0 ? douseraddrfault+0x267/0x890 ? excpagefault+0x69/0x150 entrySYSCALL64afterhwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d(CVE-2024-40978)

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

filelock: Remove locks reliably when fcntl/close race is detected

When fcntlsetlk() races with close(), it removes the created lock with dolockfilewait(). However, LSMs can allow the first dolockfilewait() that created the lock while denying the second dolockfilewait() that tries to remove the lock. Separately, posixlockfile() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).

After the bug has been triggered, use-after-free reads will occur in lockgetstatus() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.

Fix it by calling locksremoveposix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and filesstruct and is also used by filpflush().(CVE-2024-41012)

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

ocfs2: strict bound check before memcmp in ocfs2xattrfind_entry()

xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images.(CVE-2024-41016)

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

ASoC: SOF: Intel: hda: fix null deref on system suspend entry

When system enters suspend with an active stream, SOF core calls hwparamsupon_resume(). On Intel platforms with HDA DMA used to manage the link DMA, this leads to call chain of

hdadspsethwparamsuponresume() -> hdadspdaissuspend() -> hdadaisuspend() -> hdaipc4posttrigger()

A bug is hit in hdadaisuspend() as hdalinkdmacleanup() is run first, which clears hextstream->linksubstream, and then hdaipc4posttrigger() is called with a NULL sndpcmsubstream pointer.(CVE-2024-41037)

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

vfio/pci: Init the count variable in collecting hot-reset devices

The count variable is used without initialization, it results in mistakes in the device counting and crashes the userspace if the get hot reset info path is triggered.(CVE-2024-41052)

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

wifi: mac80211: Avoid address calculations via out of bounds array indexing

req->n_channels must be set before req->channels[] can be used.

This patch fixes one of the issues encountered in [1].

[ 83.964255] UBSAN: array-index-out-of-bounds in net/mac80211/scan.c:364:4 [ 83.964258] index 0 is out of range for type 'struct ieee80211channel *[]' [...] [ 83.964264] Call Trace: [ 83.964267] <TASK> [ 83.964269] dumpstacklvl+0x3f/0xc0 [ 83.964274] _ubsanhandleoutofbounds+0xec/0x110 [ 83.964278] ieee80211prephwscan+0x2db/0x4b0 [ 83.964281] _ieee80211startscan+0x601/0x990 [ 83.964291] nl80211triggerscan+0x874/0x980 [ 83.964295] genlfamilyrcvmsgdoit+0xe8/0x160 [ 83.964298] genlrcvmsg+0x240/0x270 [...]

[1] https://bugzilla.kernel.org/show_bug.cgi?id=218810(CVE-2024-41071)

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

nvme-fabrics: use reserved tag for reg read/write command

In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of adminq. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let regread32()/regread64()/regwrite32() use reserved tags. This maybe safe for nvmf:

1. For the disable ctrl path, we will not issue connect command
2. For the enable ctrl / fw activate path, since connect and reg_xx() are called serially.

So the reserved tags may still be enough while reg_xx() use reserved tags.(CVE-2024-41082)

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

ata: libata-core: Fix null pointer dereference on error

If the ataportalloc() call in atahostalloc() fails, atahostrelease() will get called.

However, the code in atahostrelease() tries to free ata_port struct members unconditionally, which can lead to the following:

BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:atahostrelease.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? _diebody.cold+0x19/0x27 ? pagefaultoops+0x15a/0x2f0 ? excpagefault+0x7e/0x180 ? asmexcpagefault+0x26/0x30 ? atahostrelease.cold+0x2f/0x6e [libata] ? atahostrelease.cold+0x2f/0x6e [libata] releasenodes+0x35/0xb0 devresreleasegroup+0x113/0x140 atahostalloc+0xed/0x120 [libata] atahostallocpinfo+0x14/0xa0 [libata] ahciinit_one+0x6c9/0xd20 [ahci]

Do not access ata_port struct members unconditionally.(CVE-2024-41098)

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

ice: Fix improper extts handling

Extts events are disabled and enabled by the application ts2phc. However, in case where the driver is removed when the application is running, a specific extts event remains enabled and can cause a kernel crash. As a side effect, when the driver is reloaded and application is started again, remaining extts event for the channel from a previous run will keep firing and the message "extts on unexpected channel" might be printed to the user.

To avoid that, extts events shall be disabled when PTP is released.(CVE-2024-42139)

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

nvmet: fix a possible leak when destroy a ctrl during qp establishment

In nvmetsqdestroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl.

However, a small window is possible where nvmetsqdestroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But before killandconfirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmetsqdestroy. This prevented the final reference drop on the ctrl.

Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that.

This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.(CVE-2024-42152)

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

i2c: pnx: Fix potential deadlock warning from deltimersync() call in isr

When deltimersync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from waitforcompletion() after a timeout so replacing the call with waitforcompletion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)

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

mm: fix crashes from deferred split racing folio migration

Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on flags when freeing, yet the flags shown are not bad: PGlocked had been set and cleared??), and VMBUGONPAGE(pagerefcount(page) == 0)s from deferredsplitscan()'s folio_put(), and a variety of other BUG and WARN symptoms implying double free by deferred split and large folio migration.

6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") was right to fix the memcg-dependent locking broken in 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"), but missed a subtlety of deferredsplitscan(): it moves folios to its own local list to work on them without splitqueuelock, during which time folio->deferredlist is not empty, but even the "right" lock does nothing to secure the folio and the list it is on.

Fortunately, deferredsplitscan() is careful to use foliotryget(): so foliomigratemapping() can avoid the race by folioundolarge_rmappable() while the old folio's reference count is temporarily frozen to 0 - adding such a freeze in the !mapping case too (originally, folio lock and unmapping and no swap cache left an anon folio unreachable, so no freezing was needed there: but the deferred split queue offers a way to reach it).(CVE-2024-42234)

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

s390/mm: Add NULL pointer check to crsttablefree() basecrstfree()

crsttablefree() used to work with NULL pointers before the conversion to ptdescs. Since crsttablefree() can be called with a NULL pointer (error handling in crsttableupgrade() add an explicit check.

Also add the same check to basecrstfree() for consistency reasons.

In real life this should not happen, since order two GFPKERNEL allocations will not fail, unless FAILPAGE_ALLOC is enabled and used.(CVE-2024-42235)

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

firmware: cs_dsp: Validate payload length before processing block

Move the payload length check in csdspload() and csdspcoeff_load() to be done before the block is processed.

The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it.(CVE-2024-42237)

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

firmware: cs_dsp: Return error if block header overflows file

Return an error from csdsppower_up() if a block header is longer than the amount of data left in the file.

The previous code in csdspload() and csdspload_coeff() would loop while there was enough data left in the file for a valid region. This protected against overrunning the end of the file data, but it didn't abort the file processing with an error.(CVE-2024-42238)

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

bpf: Fail bpftimercancel when callback is being cancelled

Given a schedule:

timer1 cb timer2 cb

bpftimercancel(timer2); bpftimercancel(timer1);

Both bpftimercancel calls would wait for the other callback to finish executing, introducing a lockup.

Add an atomict count named 'cancelling' in bpfhrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another.

Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpftimercancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors.

Background on prior attempts:

Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status.

lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false;

The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status.

It would be necessary to clear this cancelling bit once hrtimercancel is done, but lack of serialization introduced races. Another option was explored where bpftimerstart would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimercancel has finished executing, such that lockups can occur again.

Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel.(CVE-2024-42239)

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

x86/bhi: Avoid warning in #DB handler due to BHI mitigation

When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entrySYSENTERcompat() uses CLEARBRANCHHISTORY and calls the clearbhbloop() before the TF flag is cleared. This causes the #DB handler (excdebugkernel()) to issue a warning because single-step is used outside the entrySYSENTERcompat() function.

To address this issue, entrySYSENTERcompat() should use CLEARBRANCHHISTORY after making sure the TF flag is cleared.

The problem can be reproduced with the following sequence:

$ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }

$ gcc -o sysenterstep sysenterstep.c

$ ./sysenter_step Segmentation fault (core dumped)

The program is expected to crash, and the #DB handler will issue a warning.

Kernel log:

WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 excdebugkernel+0xd2/0x160 ... RIP: 0010:excdebugkernel+0xd2/0x160 ... Call Trace: <#DB> ? showregs+0x68/0x80 ? _warn+0x8c/0x140 ? excdebugkernel+0xd2/0x160 ? reportbug+0x175/0x1a0 ? handlebug+0x44/0x90 ? excinvalidop+0x1c/0x70 ? asmexcinvalidop+0x1f/0x30 ? excdebugkernel+0xd2/0x160 excdebug+0x43/0x50 asmexcdebug+0x1e/0x40 RIP: 0010:clearbhbloop+0x0/0xb0 ... </#DB> <TASK> ? entrySYSENTERcompatafterhwframe+0x6e/0x8d </TASK>

bp: Massage commit message.

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

mm/shmem: disable PMD-sized page cache if needed

For shmem files, it's possible that PMD-sized page cache can't be supported by xarray. For example, 512MB page cache on ARM64 when the base page size is 64KB can't be supported by xarray. It leads to errors as the following messages indicate when this sort of xarray entry is split.

WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xassplitalloc+0xf8/0x128 Modules linked in: binfmtmisc nftfibinet nftfibipv4 nftfibipv6 \ nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject \ nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 \ ipset rfkill nftables nfnetlink vfat fat virtioballoon drm fuse xfs \ libcrc32c crct10difce ghashce sha2ce sha256arm64 sha1ce virtionet \ netfailover virtioconsole virtioblk failover dimlib virtiommio CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xassplitalloc+0xf8/0x128 lr : splithugepagetolisttoorder+0x1c4/0x720 sp : ffff8000882af5f0 x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768 x26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858 x23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0 x5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xassplitalloc+0xf8/0x128 splithugepagetolisttoorder+0x1c4/0x720 truncateinodepartialfolio+0xdc/0x160 shmemundorange+0x2bc/0x6a8 shmemfallocate+0x134/0x430 vfsfallocate+0x124/0x2e8 ksysfallocate+0x4c/0xa0 _arm64sysfallocate+0x24/0x38 invokesyscall.constprop.0+0x7c/0xd8 doel0svc+0xb4/0xd0 el0svc+0x44/0x1d8 el0t64synchandler+0x134/0x150 el0t64_sync+0x17c/0x180

Fix it by disabling PMD-sized page cache when HPAGEPMDORDER is larger than MAXPAGECACHEORDER. As Matthew Wilcox pointed, the page cache in a shmem file isn't represented by a multi-index entry and doesn't have this limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache").(CVE-2024-42241)

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

mm/filemap: make MAXPAGECACHEORDER acceptable to xarray

Patch series "mm/filemap: Limit page cache size to that supported by xarray", v2.

Currently, xarray can't support arbitrary page cache size. More details can be found from the WARNON() statement in xassplitalloc(). In our test whose code is attached below, we hit the WARNON() on ARM64 system where the base page size is 64KB and huge page size is 512MB. The issue was reported long time ago and some discussions on it can be found here [1].

[1] https://www.spinics.net/lists/linux-xfs/msg75404.html

In order to fix the issue, we need to adjust MAXPAGECACHEORDER to one supported by xarray and avoid PMD-sized page cache if needed. The code changes are suggested by David Hildenbrand.

PATCH[1] adjusts MAXPAGECACHEORDER to that supported by xarray PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path PATCH[4] avoids PMD-sized page cache for shmem files if needed

Test program

cat test.c

define GNUSOURCE

include <stdio.h>

include <stdlib.h>

include <unistd.h>

include <string.h>

include <fcntl.h>

include <errno.h>

include <sys/syscall.h>

include <sys/mman.h>

define TESTXFSFILENAME "/tmp/data"

define TESTSHMEMFILENAME "/dev/shm/data"

define TESTMEMSIZE 0x20000000

int main(int argc, char **argv) { const char *filename; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret;

if (pgsize != 0x10000) {
    fprintf(stderr, "64KB base page size is required\n");
    return -EPERM;
}

system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled");
system("rm -fr /tmp/data");
system("rm -fr /dev/shm/data");
system("echo 1 > /proc/sys/vm/drop_caches");

/* Open xfs or shmem file */
filename = TEST_XFS_FILENAME;
if (argc > 1 && !strcmp(argv[1], "shmem"))
    filename = TEST_SHMEM_FILENAME;

fd = open(filename, O_CREAT | O_RDWR | O_TRUNC);
if (fd < 0) {
    fprintf(stderr, "Unable to open <%s>\n", filename);
    return -EIO;
}

/* Extend file size */
ret = ftruncate(fd, TEST_MEM_SIZE);
if (ret) {
    fprintf(stderr, "Error %d to ftruncate()\n", ret);
    goto cleanup;
}

/* Create VMA */
buf = mmap(NULL, TEST_MEM_SIZE,
       PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (buf == (void *)-1) {
    fprintf(stderr, "Unable to mmap <%s>\n", filename);
    goto cleanup;
}

fprintf(stdout, "mapped buffer at 0x%p\n", buf);
ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);
    if (ret) {
    fprintf(stderr, "Unable to madvise(MADV_HUGEPAGE)\n");
    goto cleanup;
}

/* Populate VMA */
ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE);
if (ret) {
    fprintf(stderr, "Error %d to madvise(MADV_POPULATE_WRITE)\n", ret);
    goto cleanup;
}

/* Punch the file to enforce xarray split */
ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,
            TEST_MEM_SIZE - pgsize, pgsize);
if (ret)
    fprintf(stderr, "Error %d to fallocate()\n", ret);

cleanup: if (buf != (void *)-1) munmap(buf, TESTMEMSIZE); if (fd > 0) close(fd);

return 0;

}

gcc test.c -o test

cat /proc/1/smaps | grep KernelPageSize | head -n 1

KernelPageSize: 64 kB

./test shmem

: ------------[ cut here ]------------ WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xassplitalloc+0xf8/0x128 Modules linked in: nftfibinet nftfibipv4 nftfibipv6 nftfib \ nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct \ nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 \ ipset nftables rfkill nfnetlink vfat fat virtioballoon \ drm fuse xfs libcrc32c crct10difce ghashce sha2ce sha256arm64 \ virtionet sha1ce netfailover failover virtioconsole virtioblk \ dimlib virtiommio CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TC ---truncated---(CVE-2024-42243)

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

tty: serial: ma35d1: Add a NULL check for of_node

The pdev->dev.of_node can be NULL if the "serial" node is absent. Add a NULL check to return an error in such cases.(CVE-2024-42248)

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

cachefiles: add missing lock protection when polling

Add missing lock protection in poll routine when iterating xarray, otherwise:

Even with RCU read lock held, only the slot of the radix tree is ensured to be pinned there, while the data structure (e.g. struct cachefilesreq) stored in the slot has no such guarantee. The poll routine will iterate the radix tree and dereference cachefilesreq accordingly. Thus RCU read lock is not adequate in this case and spinlock is needed here.(CVE-2024-42250)

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

gpio: pca953x: fix pca953xirqbussyncunlock race

Ensure that `i2clock' is held when setting interrupt latch and mask in pca953xirqbussync_unlock() in order to avoid races.

The other (non-probe) call site pca953xgpiosetmultiple() ensures the lock is held before calling pca953xwrite_regs().

The problem occurred when a request raced against irqbussync_unlock() approximately once per thousand reboots on an i.MX8MP based system.

• Normal case

  0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3

• Race case

  0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} * Wrong register * 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0(CVE-2024-42253)

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

mm: hugememory: use !CONFIG64BIT to relax huge page alignment on 32 bit machines

Yves-Alexis Perez reported commit 4ef9ad19e176 ("mm: hugememory: don't force huge page alignment on 32 bit") didn't work for x8632 [1]. It is because x8632 uses CONFIGX8632 instead of CONFIG32BIT.

!CONFIG_64BIT should cover all 32 bit machines.

[1] https://lore.kernel.org/linux-mm/CAHbLzkr1LwH3pcTgM+aGQ31ip2bKqiqEQ8=FQB+t2c3dhNKNHA@mail.gmail.com/(CVE-2024-42258)

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

drm/i915/gem: Fix Virtual Memory mapping boundaries calculation

Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access.

Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses.

Additionally, the calculations have been rewritten in a clearer and more understandable form.

[Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)

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

net/iucv: fix use after free in iucvsockclose()

iucvseverpath() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucvsockclose() will try to work with a path that has already been severed and freed by iucvcallbackconnrej() called by iucvtaskletfn().

Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucvpathsever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucvseverpath+0xc2/0xd0 [afiucv] [452744.124336] [<000003ff801e01b6>] iucvsockclose+0xa6/0x310 [afiucv] [452744.124341] [<000003ff801e08cc>] iucvsockrelease+0x3c/0xd0 [afiucv] [452744.124345] [<00000000d574794e>] _sockrelease+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sockclose+0x34/0x48 [452744.124820] [<00000000d5421642>] _fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] taskworkrun+0xbc/0xf0 [452744.124832] [<00000000d5145710>] donotifyresume+0x88/0x90 [452744.124841] [<00000000d5978096>] systemcall+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucvpathsever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt

Note that bhlocksock() is not serializing the tasklet context against process context, because the check for sockownedby_user() and corresponding handling is missing.

Ideas for a future clean-up patch: A) Correct usage of bhlocksock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv.

B) Change iucv tasklet into worker and use only locksock() in afiucv.(CVE-2024-42271)

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

sched: actct: take care of padding in struct zonesht_key

Blamed commit increased lookup key size from 2 bytes to 16 bytes, because zoneshtkey got a struct net pointer.

Make sure rhashtable_lookup() is not using the padding bytes which are not initialized.

BUG: KMSAN: uninit-value in rhtptrrcu include/linux/rhashtable.h:376 [inline] BUG: KMSAN: uninit-value in rhashtablelookup include/linux/rhashtable.h:607 [inline] BUG: KMSAN: uninit-value in rhashtablelookup include/linux/rhashtable.h:646 [inline] BUG: KMSAN: uninit-value in rhashtablelookupfast include/linux/rhashtable.h:672 [inline] BUG: KMSAN: uninit-value in tcfctflowtableget+0x611/0x2260 net/sched/actct.c:329 rhtptrrcu include/linux/rhashtable.h:376 [inline] _rhashtablelookup include/linux/rhashtable.h:607 [inline] rhashtablelookup include/linux/rhashtable.h:646 [inline] rhashtablelookupfast include/linux/rhashtable.h:672 [inline] tcfctflowtableget+0x611/0x2260 net/sched/actct.c:329 tcfctinit+0xa67/0x2890 net/sched/actct.c:1408 tcfactioninit1+0x6cc/0xb30 net/sched/actapi.c:1425 tcfactioninit+0x458/0xf00 net/sched/actapi.c:1488 tcfactionadd net/sched/actapi.c:2061 [inline] tcctlaction+0x4be/0x19d0 net/sched/actapi.c:2118 rtnetlinkrcvmsg+0x12fc/0x1410 net/core/rtnetlink.c:6647 netlinkrcvskb+0x375/0x650 net/netlink/afnetlink.c:2550 rtnetlinkrcv+0x34/0x40 net/core/rtnetlink.c:6665 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0xf52/0x1260 net/netlink/afnetlink.c:1357 netlinksendmsg+0x10da/0x11e0 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 syssendmsg+0x877/0xb60 net/socket.c:2597 _syssendmsg+0x28d/0x3c0 net/socket.c:2651 _syssendmsg net/socket.c:2680 [inline] _dosyssendmsg net/socket.c:2689 [inline] _sesyssendmsg net/socket.c:2687 [inline] _x64syssendmsg+0x307/0x4a0 net/socket.c:2687 x64syscall+0x2dd6/0x3c10 arch/x86/include/generated/asm/syscalls64.h:47 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable key created at: tcfctflowtableget+0x4a/0x2260 net/sched/actct.c:324 tcfctinit+0xa67/0x2890 net/sched/actct.c:1408(CVE-2024-42272)

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

nvme-pci: add missing condition check for existence of mapped data

nvmemapdata() is called when request has physical segments, hence the nvmeunmapdata() should have same condition to avoid dereference.(CVE-2024-42276)

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

iommu: sprd: Avoid NULL deref in sprdiommuhw_en

In sprdiommucleanup() before calling function sprdiommuhw_en() dom->sdev is equal to NULL, which leads to null dereference.

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

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

spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer

While transmitting with rx_len == 0, the RX FIFO is not going to be emptied in the interrupt handler. A subsequent transfer could then read crap from the previous transfer out of the RX FIFO into the start RX buffer. The core provides a register that will empty the RX and TX FIFOs, so do that before each transfer.(CVE-2024-42279)

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

ice: Add a per-VF limit on number of FDIR filters

While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs.

Add a similar limit in ice.(CVE-2024-42291)

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

block: fix deadlock between sdremove & sdrelease

Our test report the following hung task:

[ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] _switchto+0x174/0x338 [ 2538.459436] _schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedulepreemptdisabled+0x24/0x40 [ 2538.459453] _mutexlock+0x3ec/0xf04 [ 2538.459456] _mutexlockslowpath+0x14/0x24 [ 2538.459459] mutexlock+0x30/0xd8 [ 2538.459462] delgendisk+0xdc/0x350 [ 2538.459466] sdremove+0x30/0x60 [ 2538.459470] devicereleasedriverinternal+0x1c4/0x2c4 [ 2538.459474] devicereleasedriver+0x18/0x28 [ 2538.459478] busremovedevice+0x15c/0x174 [ 2538.459483] devicedel+0x1d0/0x358 [ 2538.459488] _scsiremovedevice+0xa8/0x198 [ 2538.459493] scsiforgethost+0x50/0x70 [ 2538.459497] scsiremovehost+0x80/0x180 [ 2538.459502] usbstordisconnect+0x68/0xf4 [ 2538.459506] usbunbindinterface+0xd4/0x280 [ 2538.459510] devicereleasedriverinternal+0x1c4/0x2c4 [ 2538.459514] devicereleasedriver+0x18/0x28 [ 2538.459518] busremovedevice+0x15c/0x174 [ 2538.459523] devicedel+0x1d0/0x358 [ 2538.459528] usbdisabledevice+0x84/0x194 [ 2538.459532] usbdisconnect+0xec/0x300 [ 2538.459537] hubevent+0xb80/0x1870 [ 2538.459541] processscheduledworks+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc

[ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] _switchto+0x174/0x338 [ 2538.461021] _schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blkqueueenter+0xc4/0x160 [ 2538.461034] blkmqallocrequest+0x120/0x1d4 [ 2538.461037] scsiexecutecmd+0x7c/0x23c [ 2538.461040] ioctlinternalcommand+0x5c/0x164 [ 2538.461046] scsisetmediumremoval+0x5c/0xb0 [ 2538.461051] sdrelease+0x50/0x94 [ 2538.461054] blkdevput+0x190/0x28c [ 2538.461058] blkdevrelease+0x28/0x40 [ 2538.461063] _fput+0xf8/0x2a8 [ 2538.461066] _fputsync+0x28/0x5c [ 2538.461070] _arm64sysclose+0x84/0xe8 [ 2538.461073] invokesyscall+0x58/0x114 [ 2538.461078] el0svccommon+0xac/0xe0 [ 2538.461082] doel0svc+0x1c/0x28 [ 2538.461087] el0svc+0x38/0x68 [ 2538.461090] el0t64synchandler+0x68/0xbc [ 2538.461093] el0t64_sync+0x1a8/0x1ac

T1: T2: sdremove delgendisk _blkmarkdiskdead blkfreezequeuestart ++q->mqfreezedepth bdevrelease mutexlock(&disk->openmutex) sdrelease scsiexecutecmd blkqueueenter waitevent(!q->mqfreezedepth) mutexlock(&disk->openmutex)

SCSI does not set GDOWNSQUEUE, so QUEUEFLAGDYING is not set in this scenario. This is a classic ABBA deadlock. To fix the deadlock, make sure we don't try to acquire disk->open_mutex after freezing the queue.(CVE-2024-42294)

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

f2fs: fix return value of f2fsconvertinline_inode()

If device is readonly, make f2fsconvertinline_inode() return EROFS instead of zero, otherwise it may trigger panic during writeback of inline inode's dirty page as below:

f2fswritesingledatapage+0xbb6/0x1e90 fs/f2fs/data.c:2888 f2fswritecachepages fs/f2fs/data.c:3187 [inline] _f2fswritedatapages fs/f2fs/data.c:3342 [inline] f2fswritedatapages+0x1efe/0x3a90 fs/f2fs/data.c:3369 dowritepages+0x359/0x870 mm/page-writeback.c:2634 filemapfdatawritewbc+0x125/0x180 mm/filemap.c:397 _filemapfdatawriterange mm/filemap.c:430 [inline] filewriteandwaitrange+0x1aa/0x290 mm/filemap.c:788 f2fsdosyncfile+0x68a/0x1ae0 fs/f2fs/file.c:276 genericwritesync include/linux/fs.h:2806 [inline] f2fsfilewriteiter+0x7bd/0x24e0 fs/f2fs/file.c:4977 callwriteiter include/linux/fs.h:2114 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xa72/0xc90 fs/readwrite.c:590 ksyswrite+0x1a0/0x2c0 fs/readwrite.c:643 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-42296)

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

ASoC: fsl: fslqmcaudio: Check devm_kasprintf() returned value

devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked.

Fix this lack and check the returned value.(CVE-2024-42298)

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

media: imx-pxp: Fix ERRPTR dereference in pxpprobe()

devmregmapinit_mmio() can fail, add a check and bail out in case of error.(CVE-2024-42303)

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

cifs: fix potential null pointer use in destroyworkqueue in initcifs error path

Dan Carpenter reported a Smack static checker warning: fs/smb/client/cifsfs.c:1981 initcifs() error: we previously assumed 'serverclosewq' could be null (see line 1895)

The patch which introduced the serverclose workqueue used the wrong oredering in error paths in init_cifs() for freeing it on errors.(CVE-2024-42307)

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

btrfs: fix extent map use-after-free when adding pages to compressed bio

At addrabiopages() we are accessing the extent map to calculate 'addsize' after we dropped our reference on the extent map, resulting in a use-after-free. Fix this by computing 'add_size' before dropping our extent map reference.(CVE-2024-42314)

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

exfat: fix potential deadlock on _exfatgetdentryset

When accessing a file with more entries than ESMAXENTRYNUM, the bh-array is allocated in _exfatgetentryset. The problem is that the bh-array is allocated with GFPKERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur.

   CPU0                CPU1
   ----                ----

kswapd balancepgdat lock(fsreclaim) exfatiterate lock(&sbi->slock) exfatreaddir exfatgetuninamefromextentry exfatgetdentryset _exfatgetdentryset kmallocarray ... lock(fsreclaim) ... evict exfatevictinode lock(&sbi->slock)

To fix this, let's allocate bh-array with GFP_NOFS.(CVE-2024-42315)

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

mm/mglru: fix div-by-zero in vmpressurecalclevel()

evictfolios() uses a second pass to reclaim folios that have gone through page writeback and become clean before it finishes the first pass, since foliorotate_reclaimable() cannot handle those folios due to the isolation.

The second pass tries to avoid potential double counting by deducting scancontrol->nrscanned. However, this can result in underflow of nrscanned, under a condition where shrinkfoliolist() does not increment nrscanned, i.e., when folio_trylock() fails.

The underflow can cause the divisor, i.e., scale=scanned+reclaimed in vmpressurecalclevel(), to become zero, resulting in the following crash:

[exception RIP: vmpressureworkfn+101] processonework at ffffffffa3313f2b

Since scancontrol->nrscanned has no established semantics, the potential double counting has minimal risks. Therefore, fix the problem by not deducting scancontrol->nrscanned in evict_folios().(CVE-2024-42316)

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

mm/huge_memory: avoid PMD-size page cache if needed

xarray can't support arbitrary page cache size. the largest and supported page cache size is defined as MAXPAGECACHEORDER by commit 099d90642a71 ("mm/filemap: make MAXPAGECACHEORDER acceptable to xarray"). However, it's possible to have 512MB page cache in the huge memory's collapsing path on ARM64 system whose base page size is 64KB. 512MB page cache is breaking the limitation and a warning is raised when the xarray entry is split as shown in the following example.

[root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char **argv) { const char *filename = TESTXFSFILENAME; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret = 0;

if (pgsize != 0x10000) {
    fprintf(stdout, "System with 64KB base page size is required!\n");
    return -EPERM;
}

system("echo 0 > /sys/devices/virtual/bdi/253:0/read_ahead_kb");
system("echo 1 > /proc/sys/vm/drop_caches");

/* Open the xfs file */
fd = open(filename, O_RDONLY);
assert(fd > 0);

/* Create VMA */
buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0);
assert(buf != (void *)-1);
fprintf(stdout, "mapped buffer at 0x%p\n", buf);

/* Populate VMA */
ret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE);
assert(ret == 0);
ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ);
assert(ret == 0);

/* Collapse VMA */
ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);
assert(ret == 0);
ret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE);
if (ret) {
    fprintf(stdout, "Error %d to madvise(MADV_COLLAPSE)\n", errno);
    goto out;
}

/* Split xarray entry. Write permission is needed */
munmap(buf, TEST_MEM_SIZE);
buf = (void *)-1;
close(fd);
fd = open(filename, O_RDWR);
assert(fd > 0);
fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,
      TEST_MEM_SIZE - pgsize, pgsize);

out: if (buf != (void *)-1) munmap(buf, TESTMEMSIZE); if (fd > 0) close(fd);

return ret;

}

[root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test [root@dhcp-10-26-1-207 ~]# /tmp/test ------------[ cut here ]------------ WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xassplitalloc+0xf8/0x128 Modules linked in: nftfibinet nftfibipv4 nftfibipv6 nftfib \ nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct \ nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 \ ipset rfkill nftables nfnetlink vfat fat virtioballoon drm fuse \ xfs libcrc32c crct10difce ghashce sha2ce sha256arm64 virtionet \ sha1ce netfailover virtioblk virtioconsole failover dimlib virtiommio CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xassplitalloc+0xf8/0x128 lr : splithugepagetolisttoorder+0x1c4/0x780 sp : ffff8000ac32f660 x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0 x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000 x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8 x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xassplitalloc+0xf8/0x128 splithugepagetolisttoorder+0x1c4/0x780 truncateinodepartialfolio+0xdc/0x160 truncateinodepagesrange+0x1b4/0x4a8 truncatepagecacherange+0x84/0xa ---truncated---(CVE-2024-42317)

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

s390/dasd: fix error checks in dasdcopypair_store()

dasdaddbusid() can return an error via ERRPTR() if an allocation fails. However, two callsites in dasdcopypairstore() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with IS_ERR() and returning the error up the stack.(CVE-2024-42320)

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

net: flowdissector: use DEBUGNETWARNON_ONCE

The following splat is easy to reproduce upstream as well as in -stable kernels. Florian Westphal provided the following commit:

d1dab4f71d37 ("net: add and use _skbgethashsymmetric_net")

but this complementary fix has been also suggested by Willem de Bruijn and it can be easily backported to -stable kernel which consists in using DEBUGNETWARNONONCE instead to silence the following splat given _skbget_hash() is used by the nftables tracing infrastructure to to identify packets in traces.

[69133.561393] ------------[ cut here ]------------ [69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flowdissector.c:1104 skbflowdissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:skbflowdissect+0x134f/0x2ad0 [69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0 [69133.562040] Call Trace: [69133.562044] <IRQ> [69133.562049] ? _warn+0x9f/0x1a0 [ 1211.841384] ? _skbflowdissect+0x107e/0x2860 [...] [ 1211.841496] ? bpfflowdissect+0x160/0x160 [ 1211.841753] _skbgethash+0x97/0x280 [ 1211.841765] ? _skbgethashsymmetric+0x230/0x230 [ 1211.841776] ? modfind+0xbf/0xe0 [ 1211.841786] ? getstackinfonoinstr+0x12/0xe0 [ 1211.841798] ? bpfksymfind+0x56/0xe0 [ 1211.841807] ? _rcureadunlock+0x2a/0x70 [ 1211.841819] nfttraceinit+0x1b9/0x1c0 [nftables] [ 1211.841895] ? nfttracenotify+0x830/0x830 [nftables] [ 1211.841964] ? getstackinfo+0x2b/0x80 [ 1211.841975] ? nftdochainarp+0x80/0x80 [nftables] [ 1211.842044] nftdochain+0x79c/0x850 nftables

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

net: missing check virtio

Two missing check in virtionethdrtoskb() allowed syzbot to crash kernels again

1. After the skbsegment function the buffer may become non-linear (nrfrags != 0), but since the SKBTXSHAREDFRAG flag is not set anywhere the _skblinearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skbheadlen(skb)) becomes true, which causes WARNONONCE in skbchecksum_help.

2. The struct skbuff and struct virtionethdr members must be mathematically related. (gsosize) must be greater than (needed) otherwise WARNONONCE. (remainder) must be greater than (needed) otherwise WARNONONCE. (remainder) may be 0 if division is without remainder.

offset+2 (4191) > skbheadlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skbchecksumhelp+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skbchecksumhelp+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ipdofragment+0xa1b/0x18b0 net/ipv4/ipoutput.c:777 ipfragment.constprop.0+0x161/0x230 net/ipv4/ipoutput.c:584 ipfinishoutputgso net/ipv4/ipoutput.c:286 [inline] _ipfinishoutput net/ipv4/ipoutput.c:308 [inline] _ipfinishoutput+0x49c/0x650 net/ipv4/ipoutput.c:295 ipfinishoutput+0x31/0x310 net/ipv4/ipoutput.c:323 NFHOOKCOND include/linux/netfilter.h:303 [inline] ipoutput+0x13b/0x2a0 net/ipv4/ipoutput.c:433 dstoutput include/net/dst.h:451 [inline] iplocalout+0xaf/0x1a0 net/ipv4/ipoutput.c:129 iptunnelxmit+0x5b4/0x9b0 net/ipv4/iptunnelcore.c:82 ipip6tunnelxmit net/ipv6/sit.c:1034 [inline] sittunnelxmit+0xed2/0x28f0 net/ipv6/sit.c:1076 _netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3545 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3561 _devqueuexmit+0x7c1/0x3d60 net/core/dev.c:4346 devqueuexmit include/linux/netdevice.h:3134 [inline] packetxmit+0x257/0x380 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3087 [inline] packetsendmsg+0x24ca/0x5240 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0xd5/0x180 net/socket.c:745 _syssendto+0x255/0x340 net/socket.c:2190 _dosyssendto net/socket.c:2202 [inline] _sesyssendto net/socket.c:2198 [inline] _x64syssendto+0xe0/0x1b0 net/socket.c:2198 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x40/0x110 arch/x86/entry/common.c:82 entrySYSCALL64after_hwframe+0x63/0x6b

Found by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)

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

ASoC: amd: Adjust error handling in case of absent codec device

acpigetfirstphysicalnode() can return NULL in several cases (no such device, ACPI table error, reference count drop to 0, etc). Existing check just emit error message, but doesn't perform return. Then this NULL pointer is passed to devmacpidevadddriver_gpios() where it is dereferenced.

Adjust this error handling by adding error code return.

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

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

scsi: lpfc: Fix a possible null pointer dereference

In function lpfcxcvrdatashow, the memory allocation with kmalloc might fail, thereby making rdpcontext a null pointer. In the following context and functions that use this pointer, there are dereferencing operations, leading to null pointer dereference.

To fix this issue, a null pointer check should be added. If it is null, use scnprintf to notify the user and return len.(CVE-2024-43821)

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

iio: Fix the sorting functionality in iiogtsbuildavailtime_table

The sorting in iiogtsbuildavailtime_table is not working as intended. It could result in an out-of-bounds access when the time is zero.

Here are more details:

1. When the gts->itimetable[i].timeus is zero, e.g., the time sequence is 3, 0, 1, the inner for-loop will not terminate and do out-of-bound writes. This is because once times[j] > new, the value new will be added in the current position and the times[j] will be moved to j+1 position, which makes the if-condition always hold. Meanwhile, idx will be added one, making the loop keep running without termination and out-of-bound write.
2. If none of the gts->itimetable[i].timeus is zero, the elements will just be copied without being sorted as described in the comment "Sort times from all tables to one and remove duplicates".

For more details, please refer to https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com.(CVE-2024-43825)

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

nfs: pass explicit offset/count to trace events

nfsfoliolength is unsafe to use without having the folio locked and a check for a NULL ->f_mapping that protects against truncations and can lead to kernel crashes. E.g. when running xfstests generic/065 with all nfs trace points enabled.

Follow the model of the XFS trace points and pass in an explіcit offset and length. This has the additional benefit that these values can be more accurate as some of the users touch partial folio ranges.(CVE-2024-43826)

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

drm/qxl: Add check for drmcvtmode

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

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

s390/uv: Don't call foliowaitwriteback() without a folio reference

foliowaitwriteback() requires that no spinlocks are held and that a folio reference is held, as documented. After we dropped the PTL, the folio could get freed concurrently. So grab a temporary reference.(CVE-2024-43832)

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

media: v4l: async: Fix NULL pointer dereference in adding ancillary links

In v4l2asynccreateancillarylinks(), ancillary links are created for lens and flash sub-devices. These are sub-device to sub-device links and if the async notifier is related to a V4L2 device, the source sub-device of the ancillary link is NULL, leading to a NULL pointer dereference. Check the notifier's sd field is non-NULL in v4l2asynccreateancillarylinks().

Sakari Ailus: Reword the subject and commit messages slightly.

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

bpf: Fix null pointer dereference in resolveprogtype() for BPFPROGTYPE_EXT

When loading a EXT program without specifying attr->attach_prog_fd, the prog->aux->dst_prog will be null. At this time, calling resolveprogtype() anywhere will result in a null pointer dereference.

Example stack trace:

[ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 8.108262] Mem abort info: [ 8.108384] ESR = 0x0000000096000004 [ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.108722] SET = 0, FnV = 0 [ 8.108827] EA = 0, S1PTW = 0 [ 8.108939] FSC = 0x04: level 0 translation fault [ 8.109102] Data abort info: [ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000 [ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000 [ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 8.112783] Modules linked in: [ 8.113120] CPU: 0 PID: 99 Comm: mayaccessdire Not tainted 6.10.0-rc3-next-20240613-dirty #1 [ 8.113230] Hardware name: linux,dummy-virt (DT) [ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.113429] pc : mayaccessdirectpktdata+0x24/0xa0 [ 8.113746] lr : addsubprogandkfunc+0x634/0x8e8 [ 8.113798] sp : ffff80008283b9f0 [ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001 [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000 [ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000 [ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff [ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720 [ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 [ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4 [ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f [ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c [ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000 [ 8.114126] Call trace: [ 8.114159] mayaccessdirectpktdata+0x24/0xa0 [ 8.114202] bpfcheck+0x3bc/0x28c0 [ 8.114214] bpfprogload+0x658/0xa58 [ 8.114227] _sysbpf+0xc50/0x2250 [ 8.114240] _arm64sysbpf+0x28/0x40 [ 8.114254] invokesyscall.constprop.0+0x54/0xf0 [ 8.114273] doel0svc+0x4c/0xd8 [ 8.114289] el0svc+0x3c/0x140 [ 8.114305] el0t64synchandler+0x134/0x150 [ 8.114331] el0t64sync+0x168/0x170 [ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403) [ 8.118672] ---[ end trace 0000000000000000 ]---

One way to fix it is by forcing attach_prog_fd non-empty when bpfprogload(). But this will lead to libbpf_probe_bpf_prog_type API broken which use verifier log to probe prog type and will log nothing if we reject invalid EXT prog before bpf_check().

Another way is by adding null check in resolveprogtype().

The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dstprog->type only for BPFPROGTYPEEXT") which wanted to correct type resolution for BPFPROGTYPETRACING programs. Before that, the type resolution of BPFPROGTYPEEXT prog actually follows the logic below:

prog->aux->dstprog ? prog->aux->dstprog->type : prog->type;

It implies that when EXT program is not yet attached to dst_prog, the prog type should be EXT itself. This code worked fine in the past. So just keep using it.

Fix this by returning prog->type for BPFPROGTYPEEXT if dst_prog is not present in resolveprog_type().(CVE-2024-43837)

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

wifi: virt_wifi: avoid reporting connection success with wrong SSID

When user issues a connection with a different SSID than the one virtwifi has advertised, the _cfg80211connectresult() will trigger the warning: WARNON(bssnot_found).

The issue is because the connection code in virtwifi does not check the SSID from user space (it only checks the BSSID), and virtwifi will call cfg80211connectresult() with WLANSTATUSSUCCESS even if the SSID is different from the one virtwifi has advertised. Eventually cfg80211 won't be able to find the cfg80211bss and generate the warning.

Fixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)

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

wifi: rtw89: Fix array index mistake in rtw89stainfogetiter()

In rtw89stainfogetiter() 'status->hegi' is compared to array size. But then 'rate->hegi' is used as array index instead of 'status->hegi'. This can lead to go beyond array boundaries in case of 'rate->hegi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake.

Fix this mistake by replacing 'rate->hegi' with 'status->hegi'.

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

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

udf: Fix bogus checksum computation in udf_rename()

Syzbot reports uninitialized memory access in udfrename() when updating checksum of '..' directory entry of a moved directory. This is indeed true as we pass on-stack diriter.fi to the udfupdatetag() and because that has only struct fileIdentDesc included in it and not the impUse or name fields, the checksumming function is going to checksum random stack contents beyond the end of the structure. This is actually harmless because the following udffiiterwritefi() will recompute the checksum from on-disk buffers where everything is properly included. So all that is needed is just removing the bogus calculation.(CVE-2024-43845)

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

lib: objagg: Fix general protection fault

The library supports aggregation of objects into other objects only if the parent object does not have a parent itself. That is, nesting is not supported.

Aggregation happens in two cases: Without and with hints, where hints are a pre-computed recommendation on how to aggregate the provided objects.

Nesting is not possible in the first case due to a check that prevents it, but in the second case there is no check because the assumption is that nesting cannot happen when creating objects based on hints. The violation of this assumption leads to various warnings and eventually to a general protection fault [1].

Before fixing the root cause, error out when nesting happens and warn.

[1] general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:mlxswspaclerpbfinsert+0x25/0x80 [...] Call Trace: <TASK> mlxswspaclatcamentryadd+0x256/0x3c0 mlxswspacltcamentrycreate+0x5e/0xa0 mlxswspacltcamvchunkmigrateone+0x16b/0x270 mlxswspacltcamvregionrehashwork+0xbe/0x510 processonework+0x151/0x370 workerthread+0x2cb/0x3e0 kthread+0xd0/0x100 retfromfork+0x34/0x50 retfromforkasm+0x1a/0x30 </TASK>(CVE-2024-43846)

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

wifi: ath12k: fix invalid memory access while processing fragmented packets

The monitor ring and the reo reinject ring share the same ring mask index. When the driver receives an interrupt for the reo reinject ring, the monitor ring is also processed, leading to invalid memory access. Since monitor support is not yet enabled in ath12k, the ring mask for the monitor ring should be removed.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1(CVE-2024-43847)

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

soc: qcom: pdr: protect locator_addr with the main mutex

If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock.(CVE-2024-43849)

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

soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove

The following warning is seen during bwmon_remove due to refcount imbalance, fix this by releasing the OPPs after use.

Logs: WARNING: at drivers/opp/core.c:1640 opptablekrefrelease+0x150/0x158 Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Call trace: opptablekrefrelease+0x150/0x158 devpmoppremovetable+0x100/0x1b4 devmpmoppoftablerelease+0x10/0x1c devmactionrelease+0x14/0x20 devresreleaseall+0xa4/0x104 deviceunbindcleanup+0x18/0x60 devicereleasedriverinternal+0x1ec/0x228 driverdetach+0x50/0x98 busremovedriver+0x6c/0xbc driverunregister+0x30/0x60 platformdriverunregister+0x14/0x20 bwmondriverexit+0x18/0x524 [iccbwmon] _arm64sysdeletemodule+0x184/0x264 invokesyscall+0x48/0x118 el0svccommon.constprop.0+0xc8/0xe8 doel0svc+0x20/0x2c el0svc+0x34/0xdc el0t64synchandler+0x13c/0x158 el0t64sync+0x190/0x194 --[ end trace 0000000000000000 ]---(CVE-2024-43850)

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

soc: xilinx: rename cpunumber1 to dummycpu_number

The per cpu variable cpunumber1 is passed to xlnxeventhandler as argument "devid", but it is not used in this function. So drop the initialization of this variable and rename it to dummycpunumber. This patch is to fix the following call trace when the kernel option CONFIGDEBUGATOMIC_SLEEP is enabled:

BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 1, name: swapper/0 preemptcount: 1, expected: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53 Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT) Call trace: dumpbacktrace+0xd0/0xe0 showstack+0x18/0x40 dumpstacklvl+0x7c/0xa0 dumpstack+0x18/0x34 _mightresched+0x10c/0x140 _mightsleep+0x4c/0xa0 _kmemcacheallocnode+0xf4/0x168 kmalloctrace+0x28/0x38 _requestpercpuirq+0x74/0x138 xlnxeventmanagerprobe+0xf8/0x298 platform_probe+0x68/0xd8(CVE-2024-43851)

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

md: fix deadlock between mddev_suspend and flush bio

Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue.

T1. the first flush is at the ending stage, it clears 'mddev->flushbio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flushbio', and attempts to queue mdsubmitflushdata(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc activeio and tries to flush, but is blocked because 'mddev->flushbio' is not NULL (set by T2). T4. mddevsuspend() is called and waits for active_io dec to 0 which is inc by T3.

T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) mdsubmitflushdata mddev->flushbio = NULL; . . mdflushrequest . mddev->flushbio = bio . queue submitflushes . . . . mdhandlerequest . . activeio + 1 . . mdflushrequest . . wait !mddev->flushbio . . . . mddevsuspend . . wait !activeio . . . submitflushes . queuework mdsubmitflushdata . //mdsubmitflushdata is already running (T1) . mdhandlerequest wait resume

The root issue is non-atomic inc/dec of activeio during flush process. activeio is dec before mdsubmitflushdata is queued, and inc soon after mdsubmitflushdata() run. mdflushrequest activeio + 1 submitflushes activeio - 1 mdsubmitflushdata mdhandlerequest activeio + 1 makerequest active_io - 1

If activeio is dec after mdhandlerequest() instead of within submitflushes(), makerequest() can be called directly intead of mdhandlerequest() in mdsubmitflushdata(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed.

Additionally, the only difference between fixing the issue and before is that there is no return error handling of makerequest(). But after previous patch cleaned mdwritestart(), makerequst() only return error in raid5makerequest() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, makerequest() will not be called in mdsubmitflushdata(). To prevent future modifications from introducing issues, add WARNON to ensure makerequest() no error is returned in this context.(CVE-2024-43855)

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

dma: fix call order in dmamfreecoherent

dmamfreecoherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list.

If this happens, there will be two entries in the devres list with the same vaddr and devresdestroy() can free the wrong entry, triggering the WARNON() in dmam_match.

Fix by destroying the devres entry before freeing the DMA allocation.

kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856)

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

f2fs: fix to truncate preallocated blocks in f2fsfileopen()

chenyuwen reports a f2fs bug as below:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011 fscryptsetbiocryptctx+0x78/0x1e8 f2fsgrabreadbio+0x78/0x208 f2fssubmitpageread+0x44/0x154 f2fsgetreaddatapage+0x288/0x5f4 f2fsgetlockdatapage+0x60/0x190 truncatepartialdatapage+0x108/0x4fc f2fsdotruncateblocks+0x344/0x5f0 f2fstruncateblocks+0x6c/0x134 f2fstruncate+0xd8/0x200 f2fsiget+0x20c/0x5ac dogarbagecollect+0x5d0/0xf6c f2fsgc+0x22c/0x6a4 f2fsdisablecheckpoint+0xc8/0x310 f2fsfillsuper+0x14bc/0x1764 mountbdev+0x1b4/0x21c f2fsmount+0x20/0x30 legacygettree+0x50/0xbc vfsgettree+0x5c/0x1b0 donewmount+0x298/0x4cc pathmount+0x33c/0x5fc _arm64sysmount+0xcc/0x15c invokesyscall+0x60/0x150 el0svccommon+0xb8/0xf8 doel0svc+0x28/0xa0 el0svc+0x24/0x84 el0t64synchandler+0x88/0xec

It is because inode.icryptinfo is not initialized during below path: - mount - f2fsfillsuper - f2fsdisablecheckpoint - f2fsgc - f2fsiget - f2fs_truncate

So, let's relocate truncation of preallocated blocks to f2fsfileopen(), after fscryptfileopen().(CVE-2024-43859)

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

usb: vhci-hcd: Do not drop references before new references are gained

At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.(CVE-2024-43883)

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

Bluetooth: MGMT: Add error handling to pair_device()

hciconnparams_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash.

Fixed by adding error handling in the function.(CVE-2024-43884)

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

padata: Fix possible divide-by-0 panic in padatamthelper()

We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time.

[ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x8664 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: eventsunbound padatamthelper [ 10.017908] RIP: 0010:padatamthelper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] <TASK> [ 10.018004] ? padatamthelper+0x39/0xb0 [ 10.018084] processonework+0x174/0x330 [ 10.018093] workerthread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] retfromfork+0x31/0x50 [ 10.018138] retfromforkasm+0x1a/0x30 [ 10.018147] </TASK>

Looking at the padatamthelper() function, the only way a divide-by-0 panic can happen is when ps->chunksize is 0. The way that chunksize is initialized in padatadomultithreaded(), chunksize can be 0 when the minchunk in the passed-in padatamtjob structure is 0.

Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are.(CVE-2024-43889)

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

tracing: Fix overflow in getfreeelt()

"tracingmap->nextelt" in getfreeelt() is at risk of overflowing.

Once it overflows, new elements can still be inserted into the tracingmap even though the maximum number of elements (max_elts) has been reached. Continuing to insert elements after the overflow could result in the tracingmap containing "tracingmap->maxsize" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using __tracing_map_insert(), it will cause an infinite loop with preemption disabled, leading to a CPU hang problem.

Fix this by preventing any further increments to "tracingmap->nextelt" once it reaches "tracingmap->maxelt".(CVE-2024-43890)

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

tracing: Have format file honor EVENTFILEFL_FREED

When eventfs was introduced, special care had to be done to coordinate the freeing of the file meta data with the files that are exposed to user space. The file meta data would have a ref count that is set when the file is created and would be decremented and freed after the last user that opened the file closed it. When the file meta data was to be freed, it would set a flag (EVENTFILEFLFREED) to denote that the file is freed, and any new references made (like new opens or reads) would fail as it is marked freed. This allowed other meta data to be freed after this flag was set (under the eventmutex).

All the files that were dynamically created in the events directory had a pointer to the file meta data and would call event_release() when the last reference to the user space file was closed. This would be the time that it is safe to free the file meta data.

A shortcut was made for the "format" file. It's i_private would point to the "call" entry directly and not point to the file's meta data. This is because all format files are the same for the same "call", so it was thought there was no reason to differentiate them. The other files maintain state (like the "enable", "trigger", etc). But this meant if the file were to disappear, the "format" file would be unaware of it.

This caused a race that could be trigger via the userevents test (that would create dynamic events and free them), and running a loop that would read the userevents format files:

In one console run:

# cd tools/testing/selftests/userevents # while true; do ./ftracetest; done

And in another console run:

# cd /sys/kernel/tracing/ # while true; do cat events/userevents/testevent/format; done 2>/dev/null

With KASAN memory checking, it would trigger a use-after-free bug report (which was a real bug). This was because the format file was not checking the file's meta data flag "EVENTFILEFL_FREED", so it would access the event that the file meta data pointed to after the event was freed.

After inspection, there are other locations that were found to not check the EVENTFILEFLFREED flag when accessing the traceeventfile. Add a new helper function: eventfilefile() that will make sure that the eventmutex is held, and will return NULL if the traceeventfile has the EVENTFILEFLFREED flag set. Have the first reference of the struct file pointer use eventfilefile() and check for NULL. Later uses can still use the eventfiledata() helper function if the eventmutex is still held and was not released since the eventfilefile() call.(CVE-2024-43891)

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

drm/amd/display: Skip Recompute DSC Params if no Stream on Link

[why] Encounter NULL pointer dereference uner mst + dsc setup.

BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drmdpatomicfindtimeslots+0x5e/0x260 [drmdisplayhelper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? _die+0x23/0x70 ? pagefaultoops+0x171/0x4e0 ? plistadd+0xbe/0x100 ? excpagefault+0x7c/0x180 ? asmexcpagefault+0x26/0x30 ? drmdpatomicfindtimeslots+0x5e/0x260 [drmdisplayhelper 0e67723696438d8e02b741593dd50d80b44c2026] ? drmdpatomicfindtimeslots+0x28/0x260 [drmdisplayhelper 0e67723696438d8e02b741593dd50d80b44c2026] computemstdscconfigsforlink+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fillplanebufferattributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] computemstdscconfigsforstate+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpudmatomiccheck+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drmatomiccheckonly+0x5c5/0xa40 drmmodeatomicioctl+0x76e/0xbc0

[how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not.

(cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cbd16fef)(CVE-2024-43895)

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

net: drop bad gso csumstart and offset in virtionet_hdr

Tighten csumstart and csumoffset checks in virtionethdrtoskb for GSO packets.

The function already checks that a checksum requested with VIRTIONETHDRFNEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation.

Syzkaller demonstrated to reach this warning in skbchecksumhelp

offset = skb_checksum_start_offset(skb);
ret = -EINVAL;
if (WARN_ON_ONCE(offset >= skb_headlen(skb)))

By injecting a TSO packet:

WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skbchecksumhelp+0x3d0/0x5b0 ipdofragment+0x209/0x1b20 net/ipv4/ipoutput.c:774 ipfinishoutputgso net/ipv4/ipoutput.c:279 [inline] _ipfinishoutput+0x2bd/0x4b0 net/ipv4/ipoutput.c:301 iptunnelxmit+0x50c/0x930 net/ipv4/iptunnelcore.c:82 iptunnelxmit+0x2296/0x2c70 net/ipv4/iptunnel.c:813 _grexmit net/ipv4/ipgre.c:469 [inline] ipgrexmit+0x759/0xa60 net/ipv4/ipgre.c:661 _netdevstartxmit include/linux/netdevice.h:4850 [inline] netdevstartxmit include/linux/netdevice.h:4864 [inline] xmitone net/core/dev.c:3595 [inline] devhardstartxmit+0x261/0x8c0 net/core/dev.c:3611 _devqueuexmit+0x1b97/0x3c90 net/core/dev.c:4261 packetsnd net/packet/afpacket.c:3073 [inline]

The geometry of the bad input packet at tcpgsosegment:

[ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) maclen=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nrfrags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ipsummed=3 completesw=0 valid=0 level=0)

Mitigate with stricter input validation.

csumoffset: for GSO packets, deduce the correct value from gsotype. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]ufofragment ignores these fields and always computes the checksum in software.

csumstart: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKBGSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload.

GSO packet are almost always CHECKSUMPARTIAL. USO packets may be CHECKSUMNONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4hwcsum/udp6hwcsumoutgoing. So no need to test for ipsummed == CHECKSUM_PARTIAL first.

This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests.(CVE-2024-43897)

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

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

drm/amd/display: Fix null pointer deref in dcn20_resource.c

Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:

mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all

and then enabling fullscreen playback (double click on the video)

The following calltrace will be seen:

[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 181.843997] #PF: supervisor instruction fetch in kernel mode [ 181.844003] #PF: errorcode(0x0010) - not-present page [ 181.844009] PGD 0 P4D 0 [ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI [ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018 [ 181.844044] RIP: 0010:0x0 [ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005 [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000 [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [ 181.844141] Call Trace: [ 181.844146] <TASK> [ 181.844153] ? showregs+0x6d/0x80 [ 181.844167] ? _die+0x24/0x80 [ 181.844179] ? pagefaultoops+0x99/0x1b0 [ 181.844192] ? douseraddrfault+0x31d/0x6b0 [ 181.844204] ? excpagefault+0x83/0x1b0 [ 181.844216] ? asmexcpagefault+0x27/0x30 [ 181.844237] dcn20getdcccompressioncap+0x23/0x30 [amdgpu] [ 181.845115] amdgpudmplanevalidatedcc.constprop.0+0xe5/0x180 [amdgpu] [ 181.845985] amdgpudmplanefillplanebufferattributes+0x300/0x580 [amdgpu] [ 181.846848] filldcplaneinfoandaddr+0x258/0x350 [amdgpu] [ 181.847734] filldcplaneattributes+0x162/0x350 [amdgpu] [ 181.848748] dmupdateplanestate.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.849791] ? dmupdateplanestate.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.850840] amdgpudmatomiccheck+0xdfe/0x1760 amdgpu

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

media: xc2028: avoid use-after-free in loadfirmwarecb()

syzkaller reported use-after-free in loadfirmwarecb() [1]. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free.

The process is as follows:

task-6504 workerthread tunerprobe <= alloc dvbfrontend [2] ... requestfirmwarenowait <= create a worker ... tunerremove <= free dvbfrontend ... requestfirmwareworkfunc <= the firmware is ready loadfirmwarecb <= but now the dvb_frontend has been freed

To fix the issue, check the dvdfrontend in loadfirmware_cb(), if it is null, report a warning and just return.

 BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504

 Call trace:
  load_firmware_cb+0x1310/0x17a0
  request_firmware_work_func+0x128/0x220
  process_one_work+0x770/0x1824
  worker_thread+0x488/0xea0
  kthread+0x300/0x430
  ret_from_fork+0x10/0x20

 Allocated by task 6504:
  kzalloc
  tuner_probe+0xb0/0x1430
  i2c_device_probe+0x92c/0xaf0
  really_probe+0x678/0xcd0
  driver_probe_device+0x280/0x370
  __device_attach_driver+0x220/0x330
  bus_for_each_drv+0x134/0x1c0
  __device_attach+0x1f4/0x410
  device_initial_probe+0x20/0x30
  bus_probe_device+0x184/0x200
  device_add+0x924/0x12c0
  device_register+0x24/0x30
  i2c_new_device+0x4e0/0xc44
  v4l2_i2c_new_subdev_board+0xbc/0x290
  v4l2_i2c_new_subdev+0xc8/0x104
  em28xx_v4l2_init+0x1dd0/0x3770

 Freed by task 6504:
  kfree+0x238/0x4e4
  tuner_remove+0x144/0x1c0
  i2c_device_remove+0xc8/0x290
  __device_release_driver+0x314/0x5fc
  device_release_driver+0x30/0x44
  bus_remove_device+0x244/0x490
  device_del+0x350/0x900
  device_unregister+0x28/0xd0
  i2c_unregister_device+0x174/0x1d0
  v4l2_device_unregister+0x224/0x380
  em28xx_v4l2_init+0x1d90/0x3770

 The buggy address belongs to the object at ffff8000d7ca2000
  which belongs to the cache kmalloc-2k of size 2048
 The buggy address is located 776 bytes inside of
  2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
 The buggy address belongs to the page:
 page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
 flags: 0x7ff800000000100(slab)
 raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
  ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

[2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)

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

drm/amd/display: Add null checker before passing variables

Checks null pointer before passing variables to functions.

This fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)

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

drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr

Check return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)

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

drm/admgpu: fix dereferencing null pointer context

When user space sets an invalid ta type, the pointer context will be empty. So it need to check the pointer context before using it(CVE-2024-43906)

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

drm/amdgpu/pm: Fix the null pointer dereference in applystateadjust_rules

Check the pointer value to fix potential null pointer dereference(CVE-2024-43907)

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

drm/amdgpu: Fix the null pointer dereference to ras_manager

Check ras_manager before using it(CVE-2024-43908)

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

drm/amdgpu/pm: Fix the null pointer dereference for smu7

optimize the code to avoid pass a null pointer (hwmgr->backend) to function smu7updateedcleakagetable.(CVE-2024-43909)

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

wifi: nl80211: disallow setting special AP channel widths

Setting the AP channel width is meant for use with the normal 20/40/... MHz channel width progression, and switching around in S1G or narrow channels isn't supported. Disallow that.(CVE-2024-43912)

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

nvme: apple: fix device reference counting

Drivers must call nvmeuninitctrl after a successful nvmeinitctrl. Split the allocation side out to make the error handling boundary easier to navigate. The apple driver had been doing this wrong, leaking the controller device memory on a tagset failure.(CVE-2024-43913)

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

md/raid5: avoid BUG_ON() while continue reshape after reassembling

Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test:

kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshaperequest+0x3f1/0xe60 Call Trace: <TASK> raid5syncrequest+0x43d/0x550 mddosync+0xb7a/0x2110 mdthread+0x294/0x2b0 kthread+0x147/0x1c0 retfromfork+0x59/0x70 retfromforkasm+0x1a/0x30 </TASK>

Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail.

Fix this panic the easy way first, by converting the BUGON() to WARNON(), and stop the reshape if checkings fail.

Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata.(CVE-2024-43914)

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

net: bridge: mcast: wait for previous gc cycles when removing port

syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call brmulticasggc() directly acquire lock now but free port the port can be freed while grp timers still running

Make sure all previous gc cycles have finished by using flush_work before freeing the port.

[1] BUG: KASAN: slab-use-after-free in brmulticastportgroupexpired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699

CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 brmulticastportgroupexpired+0x4c0/0x550 net/bridge/brmulticast.c:861 calltimerfn+0x1a3/0x610 kernel/time/timer.c:1792 expiretimers kernel/time/timer.c:1843 [inline] _runtimers+0x74b/0xaf0 kernel/time/timer.c:2417 _runtimerbase kernel/time/timer.c:2428 [inline] _runtimerbase kernel/time/timer.c:2421 [inline] runtimerbase+0x111/0x190 kernel/time/timer.c:2437(CVE-2024-44934)

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

sctp: Fix null-ptr-deref in reuseportaddsock().

syzbot reported a null-ptr-deref while accessing sk2->skreuseportcb in reuseportaddsock(). [0]

The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener.

The second listen() calls reuseportaddsock() with the first listener as sk2, where sk2->skreuseportcb is not expected to be cleared concurrently, but the close() does clear it by reuseportdetachsock().

The problem is SCTP does not properly synchronise reuseportalloc(), reuseportaddsock(), and reuseportdetach_sock().

The caller of reuseportalloc() and reuseport{add,detach}_sock() must provide synchronisation for sockets that are classified into the same reuseport group.

Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead.

1. Two sockets call listen() concurrently
2. No socket in the same group found in sctpephashtable[]
3. Two sockets call reuseport_alloc() and form two reuseport groups
4. Only one group hit first in _sctprcvlookupendpoint() receives incoming packets

Also, the reported null-ptr-deref could occur.

TCP/UDP guarantees that would not happen by holding the hash bucket lock.

Let's apply the locking strategy to _sctphashendpoint() and _sctpunhashendpoint().

KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseportaddsock+0x27e/0x5e0 net/core/sockreuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _sctphashendpoint net/sctp/input.c:762 [inline] sctphashendpoint+0x52a/0x600 net/sctp/input.c:790 sctplistenstart net/sctp/socket.c:8570 [inline] sctpinetlisten+0x767/0xa20 net/sctp/socket.c:8625 _syslistensocket net/socket.c:1883 [inline] _syslisten+0x1b7/0x230 net/socket.c:1894 _dosyslisten net/socket.c:1902 [inline] _sesyslisten net/socket.c:1900 [inline] _x64syslisten+0x5a/0x70 net/socket.c:1900 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: ---truncated---(CVE-2024-44935)

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

fou: remove warn in guegroreceive on unsupported protocol

Drop the WARNONONCE inn guegroreceive if the encapsulated type is not known or does not have a GRO handler.

Such a packet is easily constructed. Syzbot generates them and sets off this warning.

Remove the warning as it is expected and not actionable.

The warning was previously reduced from WARNON to WARNONONCE in commit 270136613bf7 ("fou: Do WARNONONCE in guegro_receive for bad proto callbacks").(CVE-2024-44940)

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

f2fs: fix to do sanity check on F2FSINLINEDATA flag in inode during GC

syzbot reports a f2fs bug as below:

------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fswriteinlinedata+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fswritesingledatapage+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fswritecachepages fs/f2fs/data.c:3133 [inline] _f2fswritedatapages fs/f2fs/data.c:3288 [inline] f2fswritedatapages+0x1efe/0x3a90 fs/f2fs/data.c:3315 dowritepages+0x35b/0x870 mm/page-writeback.c:2612 _writebacksingleinode+0x165/0x10b0 fs/fs-writeback.c:1650 writebacksbinodes+0x905/0x1260 fs/fs-writeback.c:1941 wbwriteback+0x457/0xce0 fs/fs-writeback.c:2117 wbdowriteback fs/fs-writeback.c:2264 [inline] wbworkfn+0x410/0x1090 fs/fs-writeback.c:2304 processonework kernel/workqueue.c:3254 [inline] processscheduledworks+0xa12/0x17c0 kernel/workqueue.c:3335 workerthread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244

The root cause is: inlinedata inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fsbug_on() during dirty page writeback.

Let's add sanity check on F2FSINLINEDATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.(CVE-2024-44942)

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

kcm: Serialise kcm_sendmsg() for the same socket.

syzkaller reported UAF in kcm_release(). [0]

The scenario is

1. Thread A builds a skb with MSGMORE and sets kcm->seqskb.

2. Thread A resumes building skb from kcm->seqskb but is blocked by skstreamwaitmemory()

3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue

4. Thread A faces an error and finally frees skb that is already in the write queue

5. kcm_release() does double-free the skb in the write queue

When a thread is building a MSG_MORE skb, another thread must not touch it.

Let's add a per-sk mutex and serialise kcm_sendmsg().

BUG: KASAN: slab-use-after-free in _skbdequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in _skbqueuepurgereason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in _skbqueuepurge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcmrelease+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167

CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dumpbacktrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 showstack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd0/0x124 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x178/0x518 mm/kasan/report.c:488 kasanreport+0xd8/0x138 mm/kasan/report.c:601 _asanreportload8noabort+0x20/0x2c mm/kasan/reportgeneric.c:381 _skbunlink include/linux/skbuff.h:2366 [inline] _skbdequeue include/linux/skbuff.h:2385 [inline] _skbqueuepurgereason include/linux/skbuff.h:3175 [inline] _skbqueuepurge include/linux/skbuff.h:3181 [inline] kcmrelease+0x170/0x4c8 net/kcm/kcmsock.c:1691 _sockrelease net/socket.c:659 [inline] sockclose+0xa4/0x1e8 net/socket.c:1421 _fput+0x30c/0x738 fs/filetable.c:376 _fput+0x20/0x30 fs/filetable.c:404 taskworkrun+0x230/0x2e0 kernel/taskwork.c:180 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x618/0x1f64 kernel/exit.c:871 dogroupexit+0x194/0x22c kernel/exit.c:1020 getsignal+0x1500/0x15ec kernel/signal.c:2893 dosignal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 donotifyresume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exittousermodeprepare arch/arm64/kernel/entry-common.c:169 [inline] exittousermode arch/arm64/kernel/entry-common.c:178 [inline] el0svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t64synchandler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Allocated by task 6166: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x40/0x78 mm/kasan/common.c:68 kasansaveallocinfo+0x70/0x84 mm/kasan/generic.c:626 unpoisonslabobject mm/kasan/common.c:314 [inline] _kasanslaballoc+0x74/0x8c mm/kasan/common.c:340 kasanslaballoc include/linux/kasan.h:201 [inline] slabpostallochook mm/slub.c:3813 [inline] slaballocnode mm/slub.c:3860 [inline] kmemcacheallocnode+0x204/0x4c0 mm/slub.c:3903 _allocskb+0x19c/0x3d8 net/core/skbuff.c:641 allocskb include/linux/skbuff.h:1296 [inline] kcmsendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg net/socket.c:745 [inline] socksendmsg+0x220/0x2c0 net/socket.c:768 splicetosocket+0x7cc/0xd58 fs/splice.c:889 dosplicefrom fs/splice.c:941 [inline] directspliceactor+0xec/0x1d8 fs/splice.c:1164 splicedirecttoactor+0x438/0xa0c fs/splice.c:1108 dosplicedirect_actor ---truncated---(CVE-2024-44946)

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

fuse: Initialize beyond-EOF page contents before setting uptodate

fusenotifystore(), unlike fusedoreadpage(), does not enable page zeroing (because it can be used to change partial page contents).

So fusenotifystore() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate.

The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap().

This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIGINITONALLOCDEFAULT_ON=y or the corresponding kernel command line parameter).(CVE-2024-44947)

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

drm/amdgpu: Forward soft recovery errors to userspace

As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset.

1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ (cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)(CVE-2024-44961)

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

binfmt_flat: Fix corruption when not offsetting data start

Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment.

Introduce MAXSHAREDLIBSUPDATE which depends on the state of CONFIGBINFMTFLATNODATASTART_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it.(CVE-2024-44966)

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

net: dsa: bcmsf2: Fix a possible memory leak in bcmsf2mdioregister()

bcmsf2mdioregister() calls ofphyfinddevice() and then phydeviceremove() in a loop to remove existing PHY devices. ofphyfinddevice() eventually calls busfinddevice(), which calls getdevice() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak.

This commit adds the missing phydevicefree() call to decrement the refcount via put_device() to balance the refcount.(CVE-2024-44971)