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:

tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer

Driver's probe allocates memory for RX FIFO (port->rxfifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcomgeniserialportsetup() updates the RX FIFO depth (port->rxfifo_depth) to match real device capabilities, e.g. to 32.

The RX UART handle code will read "port->rxfifodepth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN:

Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handlerxuart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0

CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dumpbacktrace.part.0+0xe0/0xf0 showstack+0x18/0x40 dumpstacklvl+0x8c/0xb8 printreport+0x188/0x488 kasanreport+0xb4/0x100 _asanstore4+0x80/0xa4 handlerxuart+0xa8/0x18c qcomgeniserialhandlerx+0x84/0x9c qcomgeniserialisr+0x24c/0x760 _handleirqeventpercpu+0x108/0x500 handleirqevent+0x6c/0x110 handlefasteoiirq+0x138/0x2cc generichandledomainirq+0x48/0x64

If the RX FIFO depth changes after probe, be sure to resize the buffer.(CVE-2022-48871)

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

wifi: mac80211: sdata can be NULL during AMPDU start

ieee80211txbasessionhandle_start() may get NULL for sdata when a deauthentication is ongoing.

Here a trace triggering the race with the hostapd test multiapfronthaulonap:

(gdb) list *drvampduaction+0x46 0x8b16 is in drvampduaction (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 mightsleep(); 394 395 sdata = getbsssdata(sdata); 396 if (!checksdataindriver(sdata)) 397 return -EIO; 398 399 tracedrvampdu_action(local, sdata, params); 400

wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTHLEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807005459-localhost 04/01/2014 Workqueue: phy3 ieee80211basessionwork [mac80211] RIP: 0010:drvampduaction+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211txbasessionhandlestart+0xd0/0x190 [mac80211] ieee80211basessionwork+0xff/0x2e0 [mac80211] processonework+0x29f/0x620 workerthread+0x4d/0x3d0 ? processonework+0x620/0x620 kthread+0xfb/0x120 ? kthreadcompleteandexit+0x20/0x20 retfrom_fork+0x22/0x30 </TASK>(CVE-2022-48875)

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

f2fs: let's avoid panic if extent_tree is not created

This patch avoids the below panic.

pc : _lookupextenttree+0xd8/0x760 lr : f2fsdowritedatapage+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace: _lookupextenttree+0xd8/0x760 f2fsdowritedatapage+0x104/0x87c f2fswritesingledatapage+0x420/0xb60 f2fswritecachepages+0x418/0xb1c _f2fswritedatapages+0x428/0x58c f2fswritedatapages+0x30/0x40 dowritepages+0x88/0x190 _writebacksingleinode+0x48/0x448 writebacksbinodes+0x468/0x9e8 _writebackinodeswb+0xb8/0x2a4 wbwriteback+0x33c/0x740 wbdowriteback+0x2b4/0x400 wbworkfn+0xe4/0x34c processonework+0x24c/0x5bc workerthread+0x3e8/0xa50 kthread+0x150/0x1b4(CVE-2022-48877)

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

regulator: da9211: Use irq handler when ready

If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us.

If we enable the IRQ handler before its structures are ready, we crash.

This patch fixes:

[ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blockingnotifiercallchain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulatornotifiercallchain+0x1c/0x2c [ 1.327825] da9211irqhandler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154(CVE-2022-48891)

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:

btrfs: fix race between quota rescan and disable leading to NULL pointer deref

If we have one task trying to start the quota rescan worker while another one is trying to disable quotas, we can end up hitting a race that results in the quota rescan worker doing a NULL pointer dereference. The steps for this are the following:

1) Quotas are enabled;

2) Task A calls the quota rescan ioctl and enters btrfsqgrouprescan(). It calls qgrouprescaninit() which returns 0 (success) and then joins a transaction and commits it;

3) Task B calls the quota disable ioctl and enters btrfsquotadisable(). It clears the bit BTRFSFSQUOTAENABLED from fsinfo->flags and calls btrfsqgroupwaitforcompletion(), which returns immediately since the rescan worker is not yet running. Then it starts a transaction and locks fsinfo->qgroupioctl_lock;

4) Task A queues the rescan worker, by calling btrfsqueuework();

5) The rescan worker starts, and calls rescanshouldstop() at the start of its while loop, which results in 0 iterations of the loop, since the flag BTRFSFSQUOTAENABLED was cleared from fsinfo->flags by task B at step 3);

6) Task B sets fsinfo->quotaroot to NULL;

7) The rescan worker tries to start a transaction and uses fsinfo->quotaroot as the root argument for btrfsstarttransaction(). This results in a NULL pointer dereference down the call chain of btrfsstarttransaction(). The stack trace is something like the one reported in Link tag below:

general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: btrfs-qgroup-rescan btrfsworkhelper RIP: 0010:starttransaction+0x48/0x10f0 fs/btrfs/transaction.c:564 Code: 48 89 fb 48 (...) RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206 RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> btrfsqgrouprescanworker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402 btrfsworkhelper+0x312/0x850 fs/btrfs/async-thread.c:280 processonework+0x877/0xdb0 kernel/workqueue.c:2289 workerthread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:308 </TASK> Modules linked in:

So fix this by having the rescan worker function not attempt to start a transaction if it didn't do any rescan work.(CVE-2023-52896)

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

Add exception protection processing for vd in axichanhandle_err function

Since there is no protection for vd, a kernel panic will be triggered here in exceptional cases.

You can refer to the processing of axichanblockxfercomplete function

The triggered kernel panic is as follows:

[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 67.848447] Mem abort info: [ 67.848449] ESR = 0x96000004 [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.848454] SET = 0, FnV = 0 [ 67.848456] EA = 0, S1PTW = 0 [ 67.848458] Data abort info: [ 67.848460] ISV = 0, ISS = 0x00000004 [ 67.848462] CM = 0, WnR = 0 [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000 [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 67.848472] Internal error: Oops: 96000004 [#1] SMP [ 67.848475] Modules linked in: dmatest [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emux2rc+ #11 [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--) [ 67.848487] pc : axichanhandleerr+0xc4/0x230 [ 67.848491] lr : axichanhandleerr+0x30/0x230 [ 67.848493] sp : ffff0803fe55ae50 [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200 [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080 [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850 [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000 [ 67.848512] x21: 0000000000000080 x20: 0000000000002000 [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000 [ 67.848521] x17: 0000000000000000 x16: 0000000000000000 [ 67.848525] x15: 0000000000000000 x14: 0000000000000000 [ 67.848529] x13: 0000000000000000 x12: 0000000000000040 [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270 [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0 [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480 [ 67.848550] x3 : dead000000000100 x2 : dead000000000122 [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168 [ 67.848559] Call trace: [ 67.848562] axichanhandleerr+0xc4/0x230 [ 67.848566] dwaxidmainterrupt+0xf4/0x590 [ 67.848569] _handleirqeventpercpu+0x60/0x220 [ 67.848573] handleirqevent+0x64/0x120 [ 67.848576] handlefasteoiirq+0xc4/0x220 [ 67.848580] _handledomainirq+0x80/0xe0 [ 67.848583] gichandleirq+0xc0/0x138 [ 67.848585] el1irq+0xc8/0x180 [ 67.848588] archcpuidle+0x14/0x2c [ 67.848591] defaultidlecall+0x40/0x16c [ 67.848594] doidle+0x1f0/0x250 [ 67.848597] cpustartupentry+0x2c/0x60 [ 67.848600] restinit+0xc0/0xcc [ 67.848603] archcallrestinit+0x14/0x1c [ 67.848606] start_kernel+0x4cc/0x500 [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1) [ 67.848613] ---[ end trace 585a97036f88203a ]---(CVE-2023-52899)

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

net/sched: act_mpls: Fix warning during failed attribute validation

The 'TCAMPLSLABEL' attribute is of 'NLAU32' type, but has a validation type of 'NLAVALIDATEFUNCTION'. This is an invalid combination according to the comment above 'struct nlapolicy':

" Meaning of `validate' field, use via NLAPOLICYVALIDATEFN: NLABINARY Validation function called for the attribute. All other Unused - but note that it's a union "

This can trigger the warning [1] in nlagetrangeunsigned() when validation of the attribute fails. Despite being of 'NLAU32' type, the associated 'min'/'max' fields in the policy are negative as they are aliased by the 'validate' field.

Fix by changing the attribute type to 'NLABINARY' which is consistent with the above comment and all other users of NLAPOLICYVALIDATEFN(). As a result, move the length validation to the validation function.

No regressions in MPLS tests:

# ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0

[1] WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118 nlagetrangeunsigned+0x1d8/0x1e0 lib/nlattr.c:117 Modules linked in: CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:nlagetrangeunsigned+0x1d8/0x1e0 lib/nlattr.c:117 [...] Call Trace: <TASK> netlinkpolicydumpwriteattr+0x23d/0x990 net/netlink/policy.c:310 netlinkpolicydumpwriteattr+0x22/0x30 net/netlink/policy.c:411 netlinkacktlvfill net/netlink/afnetlink.c:2454 [inline] netlinkack+0x546/0x760 net/netlink/afnetlink.c:2506 netlinkrcvskb+0x1b7/0x240 net/netlink/afnetlink.c:2546 rtnetlinkrcv+0x18/0x20 net/core/rtnetlink.c:6109 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x5e9/0x6b0 net/netlink/afnetlink.c:1345 netlinksendmsg+0x739/0x860 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline] syssendmsg+0x38f/0x500 net/socket.c:2482 _syssendmsg net/socket.c:2536 [inline] _syssendmsg+0x197/0x230 net/socket.c:2565 _dosyssendmsg net/socket.c:2574 [inline] _sesyssendmsg net/socket.c:2572 [inline] _x64syssendmsg+0x42/0x50 net/socket.c:2572 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd(CVE-2023-52906)

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:

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: Fix for possible memory corruption

Init Control Block is dereferenced incorrectly. Correctly dereference ICB(CVE-2024-42288)

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

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)