The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ibmvnic: don't release napi in _ibmvnicopen()

If _ibmvnicopen() encounters an error such as when setting link state, it calls releaseresources() which frees the napi structures needlessly. Instead, have _ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers.

If caller of _ibmvnicopen() is ibmvnicopen(), it should release the resources immediately. If the caller is doreset() or dohardreset(), they will release the resources on the next reset.

This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface:

[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
[102056] ibmvnic 30000003 env3: Replenished 8 pools
Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x00000010
Faulting instruction address: 0xc000000000a3c840
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
...
CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
Workqueue: events_long __ibmvnic_reset [ibmvnic]
NIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
REGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)
MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 28248484  XER: 00000004
CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
...
NIP [c000000000a3c840] napi_enable+0x20/0xc0
LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
Call Trace:
[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020
---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)

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

apparmor: Fix null pointer deref when receiving skb during sock creation

The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SKCTX(sk)->label is updated in apparmorsocketpostcreate(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set.

BUG: kernel NULL pointer dereference, address: 000000000000004c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
RIP: 0010:aa_label_next_confined+0xb/0x40
Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
PKRU: 55555554
Call Trace:
 <IRQ>
 ? __die+0x23/0x70
 ? page_fault_oops+0x171/0x4e0
 ? exc_page_fault+0x7f/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? aa_label_next_confined+0xb/0x40
 apparmor_secmark_check+0xec/0x330
 security_sock_rcv_skb+0x35/0x50
 sk_filter_trim_cap+0x47/0x250
 sock_queue_rcv_skb_reason+0x20/0x60
 raw_rcv+0x13c/0x210
 raw_local_deliver+0x1f3/0x250
 ip_protocol_deliver_rcu+0x4f/0x2f0
 ip_local_deliver_finish+0x76/0xa0
 __netif_receive_skb_one_core+0x89/0xa0
 netif_receive_skb+0x119/0x170
 ? __netdev_alloc_skb+0x3d/0x140
 vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
 vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
 __napi_poll+0x28/0x1b0
 net_rx_action+0x2a4/0x380
 __do_softirq+0xd1/0x2c8
 __irq_exit_rcu+0xbb/0xf0
 common_interrupt+0x86/0xa0
 </IRQ>
 <TASK>
 asm_common_interrupt+0x26/0x40
RIP: 0010:apparmor_socket_post_create+0xb/0x200
Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
 ? __pfx_apparmor_socket_post_create+0x10/0x10
 security_socket_post_create+0x4b/0x80
 __sock_create+0x176/0x1f0
 __sys_socket+0x89/0x100
 __x64_sys_socket+0x17/0x20
 do_syscall_64+0x5d/0x90
 ? do_syscall_64+0x6c/0x90
 ? do_syscall_64+0x6c/0x90
 ? do_syscall_64+0x6c/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)

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

scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory

There is a potential out-of-bounds access when using testbit() on a single word. The testbit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump:

 BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas

 Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965

For full log, please look at [1].

Make the allocation at least the size of sizeof(unsigned long) so that setbit() and testbit() have sufficient room for read/write operations without overwriting unallocated memory.

[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)

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

drm/amdgpu: change vm->task_info handling

This patch changes the handling and lifecycle of vm->taskinfo object. The major changes are: - vm->taskinfo is a dynamically allocated ptr now, and its uasge is reference counted. - introducing two new helper funcs for taskinfo lifecycle management - amdgpuvmgettaskinfo: reference counts up taskinfo before returning this info - amdgpuvmputtaskinfo: reference counts down taskinfo - last put to taskinfo() frees task_info from the vm.

This patch also does logistical changes required for existing usage of vm->task_info.

V2: Do not block all the prints when task_info not found (Felix)

V3: Fixed review comments from Felix - Fix wrong indentation - No debug message for -ENOMEM - Add NULL check for taskinfo - Do not duplicate the debug messages (ti vs no ti) - Get first reference of taskinfo in vminit(), put last in vmfini()

V4: Fixed review comments from Felix - fix double reference increment in createtaskinfo - change amdgpuvmgettaskinfopasid - additional changes in amdgpugem.c while porting(CVE-2024-41008)

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:

drm/radeon: check bo_va->bo is non-NULL before using it

The call to radeonvmclearfreed might clear bova->bo, so we have to check it before dereferencing it.(CVE-2024-41060)

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:

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:

powerpc/pseries: Fix scv instruction crash with kexec

kexec on pseries disables AIL (reloconexc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel.

Change the kexec sequence to disable AIL after other CPUs have been brought down.

As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all.(CVE-2024-42230)

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:

riscv/mm: Add handling for VMFAULTSIGSEGV in mmfaulterror()

Handle VMFAULTSIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.(CVE-2024-42267)

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

scsi: qla2xxx: validate nvmelocalport correctly

The driver load failed with error message,

qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef

and with a kernel crash,

BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
FS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
Call Trace:
qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
qla_register_fcport_fn+0x54/0xc0 [qla2xxx]

Exit the qlanvmeregisterremote() function when qlanvmeregisterhba() fails and correctly validate nvmelocalport.(CVE-2024-42286)

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

scsi: qla2xxx: Complete command early within lock

A crash was observed while performing NPIV and FW reset,

BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPTRT SMP NOPTI RIP: 0010:dmadirectunmapsg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? _diebody+0x1a/0x60 ? pagefaultoops+0x16f/0x4a0 ? douseraddrfault+0x174/0x7f0 ? excpagefault+0x69/0x1a0 ? asmexcpagefault+0x22/0x30 ? dmadirectunmapsg+0x51/0x1e0 ? preemptcountsub+0x96/0xe0 qla2xxxqpairspfreedma+0x29f/0x3b0 [qla2xxx] qla2xxxqpairspcompl+0x60/0x80 [qla2xxx] _qla2x00abortall_cmds+0xa2/0x450 [qla2xxx]

The command completion was done early while aborting the commands in driver unload path but outside lock to avoid the WARNON condition of performing dmafree_attr within the lock. However this caused race condition while command completion via multiple paths causing system crash.

Hence complete the command early in unload path but within the lock to avoid race condition.(CVE-2024-42287)

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

nilfs2: handle inconsistent state in nilfsbtnodecreate_block()

Syzbot reported that a buffer state inconsistency was detected in nilfsbtnodecreate_block(), triggering a kernel bug.

It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state.

So, modify nilfsbtnodecreate_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)

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

fs/ntfs3: Update log->page{mask,bits} if log->pagesize changed

If an NTFS file system is mounted to another system with different PAGESIZE from the original system, log->pagesize will change in logreplay(), but log->page{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->pagesize - pageoff" will get a negative value in the later readlogpage().(CVE-2024-42299)

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

sysctl: always initialize iuid/igid

Always initialize iuid/igid inside the sysfs core so set_ownership() can safely skip setting them.

Commit 5ec27ec735ba ("fs/proc/procsysctl.c: fix the default values of iuid/igid on /proc/sys inodes.") added defaults for iuid/igid when setownership() was not implemented. It also missed adjusting netctlset_ownership() to use the same default values in case the computation of a better value failed.(CVE-2024-42312)

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

PCI: endpoint: pci-epf-test: Make use of cached 'epcfeatures' in pciepftestcore_init()

Instead of getting the epcfeatures from pciepcgetfeatures() API, use the cached pciepftest::epcfeatures value to avoid the NULL check. Since the NULL check is already performed in pciepftestbind(), having one more check in pciepftestcoreinit() is redundant and it is not possible to hit the NULL pointer dereference.

Also with commit a01e7214bef9 ("PCI: endpoint: Remove "coreinitnotifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning:

drivers/pci/endpoint/functions/pci-epf-test.c:784 pciepftestcoreinit() error: we previously assumed 'epc_features' could be null (see line 747)

Thus, remove the redundant NULL check and also use the epcfeatures:: {msixcapable/msi_capable} flags directly to avoid local variables.

kwilczynski: commit log

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

xdp: fix invalid wait context of pagepooldestroy()

If the driver uses a page pool, it creates a page pool with pagepoolcreate(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. pagepooldestroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is memallocatordisconnect(). This function internally acquires mutex_lock().

If the driver uses XDP, it registers a memory model with xdprxqinforegmemmodel(). The xdprxqinforegmemmodel() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2.

To destroy a page pool, the driver should call both pagepooldestroy() and xdpunregmemmodel(). The xdpunregmemmodel() internally calls pagepooldestroy(). Only pagepooldestroy() decreases a reference count.

If a driver calls pagepooldestroy() then xdpunregmemmodel(), we will face an invalid wait context warning. Because xdpunregmemmodel() calls pagepooldestroy() with rcureadlock(). The pagepooldestroy() internally acquires mutex_lock().

Splat looks like:

[ BUG: Invalid wait context ]

6.10.0-rc6+ #4 Tainted: G W

ethtool/1806 is trying to lock: ffffffff90387b90 (memidlock){+.+.}-{4:4}, at: memallocatordisconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <TASK> dumpstacklvl+0x7e/0xc0 lockacquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? _pfxmarklock.part.0+0x10/0x10 ? _pfxlockacquire+0x10/0x10 lockacquire+0x1b3/0x580 ? memallocatordisconnect+0x73/0x150 ? wakeupklogd.part.0+0x16/0xc0 ? _pfxlockacquire+0x10/0x10 ? dumpstacklvl+0x91/0xc0 _mutexlock+0x15c/0x1690 ? memallocatordisconnect+0x73/0x150 ? _pfxprbreadvalid+0x10/0x10 ? memallocatordisconnect+0x73/0x150 ? _pfxllistaddbatch+0x10/0x10 ? consoleunlock+0x193/0x1b0 ? lockdephardirqson+0xbe/0x140 ? _pfxmutexlock+0x10/0x10 ? ticknohztickstopped+0x16/0x90 ? irqworkqueuelocal+0x1e5/0x330 ? irqworkqueue+0x39/0x50 ? _wakeupklogd.part.0+0x79/0xc0 ? memallocatordisconnect+0x73/0x150 memallocatordisconnect+0x73/0x150 ? _pfxmemallocatordisconnect+0x10/0x10 ? markheldlocks+0xa5/0xf0 ? rcuiswatching+0x11/0xb0 pagepoolrelease+0x36e/0x6d0 pagepooldestroy+0xd7/0x440 xdpunregmemmodel+0x1a7/0x2a0 ? _pfxxdpunregmemmodel+0x10/0x10 ? kfree+0x125/0x370 ? bnxtfreering.isra.0+0x2eb/0x500 ? bnxtfreemem+0x5ac/0x2500 xdprxqinfounreg+0x4a/0xd0 bnxtfreemem+0x1356/0x2500 bnxtclosenic+0xf0/0x3b0 ? _pfxbnxtclosenic+0x10/0x10 ? ethnlparsebit+0x2c6/0x6d0 ? _pfxnlavalidateparse+0x10/0x10 ? pfxethnlparsebit+0x10/0x10 bnxtsetfeatures+0x2a8/0x3e0 _netdevupdatefeatures+0x4dc/0x1370 ? ethnlparsebitset+0x4ff/0x750 ? _pfxethnlparsebitset+0x10/0x10 ? _pfxnetdevupdatefeatures+0x10/0x10 ? markheldlocks+0xa5/0xf0 ? _rawspinunlockirqrestore+0x42/0x70 ? _pmruntimeresume+0x7d/0x110 ethnlset_features+0x32d/0xa20

To fix this problem, it uses rhashtablelookupfast() instead of rhashtablelookup() with rcureadlock(). Using xa without rcureadlock() here is safe. xa is freed by _xdpmemallocatorrcufree() and this is called by callrcu() of memxaremove(). The memxaremove() is called by pagepooldestroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcureadlock() for pagepool_destroy() is safe.(CVE-2024-43834)

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

block: initialize integrity buffer to zero before writing it to media

Metadata added by biointegrityprep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory.

Fix this by adding the _GFPZERO flag to allocations for writes.(CVE-2024-43854)

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:

ext4: sanity check for NULL pointer after ext4forceshutdown

Test case: 2 threads write short inline data to a file. In ext4pagemkwrite the resulting inline data is converted. Handling ext4grplockederror with description "block bitmap and bg descriptor inconsistent: X vs Y free clusters" calls ext4forceshutdown. The conversion clears EXT4STATEMAYINLINEDATA but fails for ext4destroyinlinedatanolock and ext4markilocdirty due to ext4forcedshutdown. The restoration of inline data fails for the same reason not setting EXT4STATEMAYINLINEDATA. Without the flag set a regular process path in ext4dawrite_end follows trying to dereference page folio private pointer that has not been set. The fix calls early return with -EIO error shall the pointer to private be NULL.

Sample crash report:

Unable to handle kernel paging request at virtual address dfff800000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfff800000000004] address between user and kernel address ranges Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _blockcommitwrite+0x64/0x2b0 fs/buffer.c:2167 lr : _blockcommitwrite+0x3c/0x2b0 fs/buffer.c:2160 sp : ffff8000a1957600 x29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0 x26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000 x23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020 x20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196 x17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0 x14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000 x5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020 x2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0 Call trace: _blockcommitwrite+0x64/0x2b0 fs/buffer.c:2167 blockwriteend+0xb4/0x104 fs/buffer.c:2253 ext4dadowriteend fs/ext4/inode.c:2955 [inline] ext4dawriteend+0x2c4/0xa40 fs/ext4/inode.c:3028 genericperformwrite+0x394/0x588 mm/filemap.c:3985 ext4bufferedwriteiter+0x2c0/0x4ec fs/ext4/file.c:299 ext4filewriteiter+0x188/0x1780 callwriteiter include/linux/fs.h:2110 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0x968/0xc3c fs/readwrite.c:590 ksyswrite+0x15c/0x26c fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _arm64syswrite+0x7c/0x90 fs/readwrite.c:652 _invokesyscall arch/arm64/kernel/syscall.c:34 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:133 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:152 el0svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t64synchandler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t64sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: 97f85911 f94002da 91008356 d343fec8 (38796908)

---[ end trace 0000000000000000 ]---

Code disassembly (best guess): 0: 97f85911 bl 0xffffffffffe16444 4: f94002da ldr x26, [x22] 8: 91008356 add x22, x26, #0x20 c: d343fec8 lsr x8, x22, #3 * 10: 38796908 ldrb w8, [x8, x25] <-- trapping instruction(CVE-2024-43898)

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

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:

jfs: Fix shift-out-of-bounds in dbDiscardAG

When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative.

This patch fixes the issue by exiting the loop directly when negative shift is found.(CVE-2024-44938)

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:

netfilter: ctnetlink: use helper function to calculate expect ID

Delete expectation path is missing a call to the nfexpectget_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.(CVE-2024-44944)

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)