OESA-2024-2296

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 &lt;8b&gt; 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:
 &lt;IRQ&gt;
 ? __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
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 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 &lt;55&gt; 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:

netfilter: nf_tables: use timestamp to check for set element timeout

Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area.

Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished.

.lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to check the current time since it runs asynchronously from a workqueue.(CVE-2024-27397)

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

Bluetooth: msft: fix slab-use-after-free in msftdoclose()

Tying the msft->data lifetime to hdev by freeing it in hcireleasedev() to fix the following case:

[use] msftdoclose() msft = hdev->msftdata; if (!msft) ...(1) <- passed. return; mutexlock(&msft->filter_lock); ...(4) <- used after freed.

[free] msftunregister() msft = hdev->msftdata; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed.

================================================================== BUG: KASAN: slab-use-after-free in _mutexlockcommon kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in _mutex_lock+0x8f/0xc30 kernel/locking/mutex.c:752 Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309(CVE-2024-36012)

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

ppdev: Add an error check in register_device

In registerdevice, the return value of idasimpleget is unchecked, in witch idasimple_get will use an invalid index value.

To address this issue, index should be checked after idasimpleget. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.(CVE-2024-36015)

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

Bluetooth: qca: fix info leak when fetching fw build id

Add the missing sanity checks and move the 255-byte build-id buffer off the stack to avoid leaking stack data through debugfs in case the build-info reply is malformed.(CVE-2024-36032)

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

net/sched: taprio: extend minimum interval restriction to entire cycle too

It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals.

We need one more restriction, which is that the cycle time itself must be larger than N * ETHZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycletime)" branch. This way covers both conditions and scenarios.

Add a selftest which illustrates the issue triggered by syzbot.(CVE-2024-36244)

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

Bluetooth: qca: add missing firmware sanity checks

Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.(CVE-2024-36880)

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

mptcp: ensure snd_nxt is properly initialized on connect

Christoph reported a splat hinting at a corrupted snd_una:

WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 mptcpcleanuna+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcpworker RIP: 0010:mptcpcleanuna+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> _mptcpcleanunawakeup net/mptcp/protocol.c:1055 [inline] mptcpcleanunawakeup net/mptcp/protocol.c:1062 [inline] _mptcpretrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcpworker+0x434/0x740 net/mptcp/protocol.c:2767 processonework+0x1e0/0x560 kernel/workqueue.c:3254 processscheduledworks kernel/workqueue.c:3335 [inline] workerthread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 retfromfork+0x44/0x50 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:243 </TASK>

When fallback to TCP happens early on a client socket, sndnxt is not yet initialized and any incoming ack will copy such value into snduna. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice.

Instead address the issue always initializing sndnxt (and writeseq, for consistency) at connect time.(CVE-2024-36889)

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

usb: gadget: ffs: Fix race between aiocancel() and AIO request complete

FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following:

DWC3 Gadget                               FFS Application

dwc3gadgetsoftdisconnect() ... --> dwc3stopactivetransfers() --> dwc3gadgetgiveback(-ESHUTDOWN) --> ffsepfileasynciocomplete() ffsaiocancel() --> usbepfreerequest() --> usbep_dequeue()

There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (iodata->req) the FFS application is also referencing it for the usbep_dequeue() call. This can lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently") relocated the usbepfreerequest() into ffsepfileasynciocomplete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffsepfileasynciocomplete(), as usbep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock.

Fix this issue by moving the usbepfreerequest() back to ffsusercopyworker(), and ensuring that it explicitly sets iodata->req to NULL after freeing it within the ffs->epslock. This resolves the race condition above, as the ffsaiocancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffsusercopy_work() not freeing the USB request until the AIO cancel is done referencing it.

This fix depends on commit b566d38857fc ("usb: gadget: ffs: use iodata->status consistently")(CVE-2024-36894)

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

Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted

In CoCo VMs it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

The VMBus ring buffer code could free decrypted/shared pages if setmemorydecrypted() fails. Check the decrypted field in the struct vmbus_gpadl for the ring buffers to decide whether to free the memory.(CVE-2024-36909)

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

uiohvgeneric: Don't free decrypted memory

The VMBus device UIO driver could free decrypted/shared pages if setmemorydecrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.(CVE-2024-36910)

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

hv_netvsc: Don't free decrypted memory

The netvsc driver could free decrypted/shared pages if setmemorydecrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.(CVE-2024-36911)

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

Drivers: hv: vmbus: Leak pages if setmemoryencrypted() fails

VMBus code could free decrypted pages if setmemoryencrypted()/decrypted() fails. Leak the pages if this happens.(CVE-2024-36913)

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

nfc: llcp: fix nfcllcpsetsockopt() unsafe copies

syzbot reported unsafe calls to copyfromsockptr() [1]

Use copysafefrom_sockptr() instead.

[1]

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078

CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 dosocksetsockopt+0x3b1/0x720 net/socket.c:2311 _syssetsockopt+0x1ae/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfd/0x240 entrySYSCALL64afterhwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIGRAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)

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

bpf: Check bloom filter map value size

This patch adds a missing check to bloom filter creating, rejecting values above KMALLOCMAXSIZE. This brings the bloom map in line with many other map types.

The lack of this protection can cause kernel crashes for value sizes that overflow int's. Such a crash was caught by syzkaller. The next patch adds more guard-rails at a lower level.(CVE-2024-36918)

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

scsi: mpi3mr: Avoid memcpy field-spanning write WARNING

When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver prints this WARNING message:

memcpy: detected field-spanning write (size 128) of single field "bsgreplybuf->replybuf" at drivers/scsi/mpi3mr/mpi3mrapp.c:1658 (size 1) WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mrapp.c:1658 mpi3mrbsg_request+0x6b12/0x7f10 [mpi3mr]

The cause of the WARN is 128 bytes memcpy to the 1 byte size array "_u8 replaybuf[1]" in the struct mpi3mrbsginreplybuf. The array is intended to be a flexible length array, so the WARN is a false positive.

To suppress the WARN, remove the constant number '1' from the array declaration and clarify that it has flexible length. Also, adjust the memory allocation size to match the change.(CVE-2024-36920)

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

wifi: iwlwifi: mvm: guard against invalid STA ID on removal

Guard against invalid station IDs in iwlmvmmldrmsta_id as that would result in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error handling.(CVE-2024-36921)

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

wifi: iwlwifi: read txq->read_ptr under lock

If we read txq->readptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARNONCE() a little later. Fix that by reading txq->read_ptr under lock.(CVE-2024-36922)

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

ipv4: Fix uninit-value access in _ipmake_skb()

KMSAN reported uninit-value access in _ipmakeskb() [1]. _ipmakeskb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IPHDRINCL changes HDRINCL while _ipmakeskb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN.

Check FLOWIFLAGKNOWNNH on fl4->flowi4flags instead of testing HDRINCL on the socket.

Also, fl4->fl4icmptype and fl4->fl4icmpcode are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4initoutput(), but we should not rely on specific union layout.

Initialize these explicitly in raw_sendmsg().

[1] BUG: KMSAN: uninit-value in _ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 _ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipfinishskb include/net/ip.h:243 [inline] ippushpendingframes+0x4c/0x5c0 net/ipv4/ipoutput.c:1508 rawsendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x274/0x3c0 net/socket.c:745 _syssendto+0x62c/0x7b0 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x5f6/0xc50 mm/slub.c:3888 kmallocreserve+0x13c/0x4a0 net/core/skbuff.c:577 _allocskb+0x35a/0x7c0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] _ipappenddata+0x49ab/0x68c0 net/ipv4/ipoutput.c:1128 ipappenddata+0x1e7/0x260 net/ipv4/ipoutput.c:1365 rawsendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x274/0x3c0 net/socket.c:745 _syssendto+0x62c/0x7b0 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x6d/0x75

CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014(CVE-2024-36927)

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

efi/unaccepted: touch soft lockup during memory accept

Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance") has released the spinlock so other CPUs can do memory acceptance in parallel and not triggers softlockup on other CPUs.

However the softlock up was intermittent shown up if the memory of the TD guest is large, and the timeout of softlockup is set to 1 second:

RIP: 0010:rawspinunlockirqrestore Call Trace: ? _hrtimerrunqueues <IRQ> ? hrtimerinterrupt ? watchdogtimerfn ? _sysvecapictimerinterrupt ? _pfxwatchdogtimerfn ? sysvecapictimerinterrupt </IRQ> ? _hrtimerrunqueues <TASK> ? hrtimerinterrupt ? asmsysvecapictimerinterrupt ? _rawspinunlockirqrestore ? _sysvecapictimerinterrupt ? sysvecapictimerinterrupt acceptmemory trytoacceptmemory dohugepmdanonymouspage getpagefromfreelist _handlemmfault _allocpages _folioalloc ? _tdxhypercall handlemmfault vmaallocfolio douseraddrfault dohugepmdanonymouspage excpagefault ? _dohugepmdanonymouspage asmexcpagefault _handlemm_fault

When the local irq is enabled at the end of accept_memory(), the softlockup detects that the watchdog on single CPU has not been fed for a while. That is to say, even other CPUs will not be blocked by spinlock, the current CPU might be stunk with local irq disabled for a while, which hurts not only nmi watchdog but also softlockup.

Chao Gao pointed out that the memory accept could be time costly and there was similar report before. Thus to avoid any softlocup detection during this stage, give the softlockup a flag to skip the timeout check at the end of acceptmemory(), by invoking touchsoftlockup_watchdog().(CVE-2024-36936)

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

pinctrl: core: delete incorrect free in pinctrl_enable()

The "pctldev" struct is allocated in devmpinctrlregisterandinit(). It's a devm_ managed pointer that is freed by devmpinctrldevrelease(), so freeing it in pinctrlenable() will lead to a double free.

The devmpinctrldev_release() function frees the pindescs and destroys the mutex as well.(CVE-2024-36940)

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

wifi: nl80211: don't free NULL coalescing rule

If the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)

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

phonet: fix rtmphonetnotify() skb allocation

fill_route() stores three components in the skb:

struct rtmsg
RTA_DST (u8)
RTA_OIF (u32)

Therefore, rtmphonetnotify() should use

NLMSGALIGN(sizeof(struct rtmsg)) + nlatotalsize(1) + nlatotal_size(4)(CVE-2024-36946)

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

tracefs: Reset permissions on remount if permissions are options

There's an inconsistency with the way permissions are handled in tracefs. Because the permissions are generated when accessed, they default to the root inode's permission if they were never set by the user. If the user sets the permissions, then a flag is set and the permissions are saved via the inode (for tracefs files) or an internal attribute field (for eventfs).

But if a remount happens that specify the permissions, all the files that were not changed by the user gets updated, but the ones that were are not. If the user were to remount the file system with a given permission, then all files and directories within that file system should be updated.

This can cause security issues if a file's permission was updated but the admin forgot about it. They could incorrectly think that remounting with permissions set would update all files, but miss some.

For example:

# cd /sys/kernel/tracing # chgrp 1002 currenttracer # ls -l [..] -rw-r----- 1 root root 0 May 1 21:25 buffersizekb -rw-r----- 1 root root 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root root 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root root 0 May 1 21:25 dynamicevents -r--r----- 1 root root 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root root 0 May 1 21:25 enabled_functions

Where current_tracer now has group "lkp".

# mount -o remount,gid=1001 . # ls -l -rw-r----- 1 root tracing 0 May 1 21:25 buffersizekb -rw-r----- 1 root tracing 0 May 1 21:25 buffersubbufsizekb -r--r----- 1 root tracing 0 May 1 21:25 buffertotalsizekb -rw-r----- 1 root lkp 0 May 1 21:25 currenttracer -rw-r----- 1 root tracing 0 May 1 21:25 dynamicevents -r--r----- 1 root tracing 0 May 1 21:25 dynftracetotalinfo -r--r----- 1 root tracing 0 May 1 21:25 enabledfunctions

Everything changed but the "current_tracer".

Add a new link list that keeps track of all the tracefs_inodes which has the permission flags that tell if the file/dir should use the root inode's permission or not. Then on remount, clear all the flags so that the default behavior of using the root inode's permission is done for all files and directories.(CVE-2024-36963)

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

net: fix _dstnegative_advice() race

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

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

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

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

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

Many thanks to Clement Lecigne for tracking this issue.

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

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

net: stmmac: move the EST lock to struct stmmac_priv

Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization.

DEBUGLOCKSWARNON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 _mutexlock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _mutexlock+0xd84/0x1068 lr : _mutexlock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: _mutexlock+0xd84/0x1068 mutexlocknested+0x28/0x34 tcsetuptaprio+0x118/0x68c stmmacsetuptc+0x50/0xf0 tapriochange+0x868/0xc9c(CVE-2024-38594)

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

net/mlx5e: Fix netif state handling

mlx5esuspend cleans resources only if netifdevicepresent() returns true. However, mlx5eresume changes the state of netif, via mlx5enicenable, only if regstate == NETREGREGISTERED. In the below case, the above leads to NULL-ptr Oops[1] and memory leaks:

mlx5eprobe _mlx5eresume mlx5eattachnetdev mlx5enicenable <-- netdev not reg, not calling netifdeviceattach() registernetdev <-- failed for some reason. ERRORFLOW: mlx5esuspend <-- netifdevicepresent return false, resources aren't freed :(

Hence, clean resources in this case as well.

[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0forupstreammindebug202309051601 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at0xffffffffffffffd6. RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Call Trace: <TASK> ? _die+0x20/0x60 ? pagefaultoops+0x14c/0x3c0 ? excpagefault+0x75/0x140 ? asmexcpagefault+0x22/0x30 notifiercallchain+0x35/0xb0 blockingnotifiercallchain+0x3d/0x60 mlx5blockingnotifiercallchain+0x22/0x30 [mlx5core] mlx5coreuplinknetdeveventreplay+0x3e/0x60 [mlx5core] mlx5mdevnetdevtrack+0x53/0x60 [mlx5ib] mlx5ibroceinit+0xc3/0x340 [mlx5ib] _mlx5ibadd+0x34/0xd0 [mlx5ib] mlx5rprobe+0xe1/0x210 [mlx5ib] ? auxiliarymatchid+0x6a/0x90 auxiliarybusprobe+0x38/0x80 ? driversysfsadd+0x51/0x80 reallyprobe+0xc9/0x3e0 ? driverprobedevice+0x90/0x90 _driverprobedevice+0x80/0x160 driverprobedevice+0x1e/0x90 _deviceattachdriver+0x7d/0x100 busforeachdrv+0x80/0xd0 _deviceattach+0xbc/0x1f0 busprobedevice+0x86/0xa0 deviceadd+0x637/0x840 _auxiliarydeviceadd+0x3b/0xa0 addadev+0xc9/0x140 [mlx5core] mlx5rescandriverslocked+0x22a/0x310 [mlx5core] mlx5registerdevice+0x53/0xa0 [mlx5core] mlx5initonedevllocked+0x5c4/0x9c0 [mlx5core] mlx5initone+0x3b/0x60 [mlx5core] probeone+0x44c/0x730 [mlx5core] localpciprobe+0x3e/0x90 pcideviceprobe+0xbf/0x210 ? kernfscreatelink+0x5d/0xa0 ? sysfsdocreatelinksd+0x60/0xc0 reallyprobe+0xc9/0x3e0 ? driverprobedevice+0x90/0x90 _driverprobedevice+0x80/0x160 driverprobedevice+0x1e/0x90 _deviceattachdriver+0x7d/0x100 busforeachdrv+0x80/0xd0 _deviceattach+0xbc/0x1f0 pcibusadddevice+0x54/0x80 pciiovaddvirtfn+0x2e6/0x320 sriovenable+0x208/0x420 mlx5coresriovconfigure+0x9e/0x200 [mlx5core] sriovnumvfsstore+0xae/0x1a0 kernfsfopwriteiter+0x10c/0x1a0 vfswrite+0x291/0x3c0 ksyswrite+0x5f/0xe0 dosyscall64+0x3d/0x90 entrySYSCALL64afterhwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000 ]---(CVE-2024-38608)

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

ipv6: sr: fix invalid unregister error path

The error path of seg6init() is wrong in case CONFIGIPV6SEG6LWTUNNEL is not defined. In that case if seg6hmacinit() fails, the genlunregisterfamily() isn't called.

This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregisterpernetsubsys() with genlunregisterfamily() in this error path.(CVE-2024-38612)

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

net: ena: Add validation for completion descriptors consistency

Validate that first flag is set only for the first descriptor in multi-buffer packets. In case of an invalid descriptor, a reset will occur. A new reset reason for RX data corruption has been added.(CVE-2024-40999)

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

nilfs2: add missing check for inode numbers on directory entries

Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lruaddfn().

As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfsevictinode(), which is called from iput(), tries to delete that inode (ifile inode in this case).

The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking.

Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages.

Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.(CVE-2024-42104)

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

leds: an30259a: Use devmmutexinit() for mutex initialization

In this driver LEDs are registered using devmledclassdevregister() so they are automatically unregistered after module's remove() is done. ledclassdevunregister() calls module's ledset_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.(CVE-2024-42128)

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

s390/pkey: Wipe sensitive data on failure

Wipe sensitive data from stack also if the copytouser() fails.(CVE-2024-42157)

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

crypto: aead,cipher - zeroize key buffer after use

I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key.(CVE-2024-42229)

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

libceph: fix race between delayedwork() and cephmonc_stop()

The way the delayed work is handled in cephmoncstop() is prone to races with monfault() and possibly also finishhunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after canceldelayedworksync() runs -- _closesession() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in monfault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.

To fix this:

clear monc->curmon and monc->hunting as part of closing the session in cephmonc_stop()
bail from delayedwork() if monc->curmon is cleared, similar to how it's done in monfault() and finishhunting() (based on monc->hunting)
call canceldelayedwork_sync() after the session is closed(CVE-2024-42232)

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

usb: gadget: configfs: Prevent OOB read/write in usbstringcopy()

Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form if (str[0 - 1] == '\n') followed closely by an OOB write in the formstr[0 - 1] = '\0'`.

There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.(CVE-2024-42236)

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

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference sp after calling dev_kfree_skb(sp).(CVE-2024-42280)

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

net: nexthop: Initialize all fields in dumped nexthops

struct nexthopgrp contains two reserved fields that are not initialized by nlaputnhgroup(), and carry garbage. This can be observed e.g. with strace (edited for clarity):

# ip nexthop add id 1 dev lo
# ip nexthop add id 101 group 1
# strace -e recvmsg ip nexthop get id 101
...
recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
             [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52

The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.(CVE-2024-42283)

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:

scsi: qla2xxx: During vport delete send async logout explicitly

During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, ehabort was issued and aborted (fastfail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting.

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] PREEMPT SMP NOPTI Workqueue: qla2xxxwq qladowork [qla2xxx] RIP: 0010:dmadirectunmapsg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxxqpairspfreedma+0x417/0x4e0 ? qla2xxxqpairspcompl+0x10d/0x1a0 ? qla2x00statusentry+0x768/0x2830 ? newidlebalance+0x2f0/0x430 ? dequeueentity+0x100/0x3c0 ? qla24xxprocessresponsequeue+0x6a1/0x19e0 ? _schedule+0x2d5/0x1140 ? qladowork+0x47/0x60 ? processonework+0x267/0x440 ? processonework+0x440/0x440 ? workerthread+0x2d/0x3d0 ? processonework+0x440/0x440 ? kthread+0x156/0x180 ? setkthreadstruct+0x50/0x50 ? retfrom_fork+0x22/0x30 </TASK>

Send out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)

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

irqchip/imx-irqsteer: Handle runtime power management correctly

The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing:

BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: _schedulebug+0x54/0x6c _schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedulepreemptdisabled+0x24/0x40 _mutexlock.constprop.0+0x2c0/0x540 _mutexlockslowpath+0x14/0x20 mutexlock+0x48/0x54 clkpreparelock+0x44/0xa0 clkprepare+0x20/0x44 imxirqsteerresume+0x28/0xe0 pmgenericruntimeresume+0x2c/0x44 _genpdruntimeresume+0x30/0x80 genpdruntimeresume+0xc8/0x2c0 _rpmcallback+0x48/0x1d8 rpmcallback+0x6c/0x78 rpmresume+0x490/0x6b4 _pmruntimeresume+0x50/0x94 irqchippmget+0x2c/0xa0 _irqdosethandler+0x178/0x24c irqsetchainedhandleranddata+0x60/0xa4 mxcgpio_probe+0x160/0x4b0

Cure this by implementing the irqbuslock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context.

tglx: Rewrote change log, added Fixes tag

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

kobjectuevent: Fix OOB access within zapmodalias_env()

zapmodaliasenv() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)

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:

ext4: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:

BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> makeindexeddir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4addentry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4rename fs/ext4/namei.c:3936 [inline] ext4rename2+0x26e5/0x4370 fs/ext4/namei.c:4214

[...]

The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue.

do_split
  unsigned split
  dx_make_map
   count = 1
  split = count/2 = 0;
  continued = hash2 == map[split - 1].hash;
   ---&gt; map[4294967295]

The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows:

bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024

So when renaming dentry1 increases its namelen length by 1, neither hole nor free is sufficient to hold the new dentry, and makeindexed_dir() is called.

In makeindexeddir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1.

Therefore add the ext4checkdx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.(CVE-2024-42305)

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

udf: Avoid using corrupted block bitmap buffer

When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not.(CVE-2024-42306)

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

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

drm/gma500: fix null pointer dereference in psbintellvdsgetmodes

In psbintellvdsgetmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmodeduplicate(). Add a check to avoid npd.(CVE-2024-42309)

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

hfs: fix to initialize fields of hfsinodeinfo after hfsallocinode()

Syzbot reports uninitialized value access issue as below:

loop0: detected capacity change from 0 to 64

BUG: KMSAN: uninit-value in hfsrevalidatedentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfsrevalidatedentry+0x307/0x3f0 fs/hfs/sysdep.c:30 drevalidate fs/namei.c:862 [inline] lookupfast+0x89e/0x8e0 fs/namei.c:1649 walkcomponent fs/namei.c:2001 [inline] linkpathwalk+0x817/0x1480 fs/namei.c:2332 pathlookupat+0xd9/0x6f0 fs/namei.c:2485 filenamelookup+0x22e/0x740 fs/namei.c:2515 userpathatempty+0x8b/0x390 fs/namei.c:2924 userpathat include/linux/namei.h:57 [inline] domount fs/namespace.c:3689 [inline] _dosysmount fs/namespace.c:3898 [inline] _sesysmount+0x66b/0x810 fs/namespace.c:3875 _x64sysmount+0xe4/0x140 fs/namespace.c:3875 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

BUG: KMSAN: uninit-value in hfsextreadextent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfsgetblock+0x92d/0x1620 fs/hfs/extent.c:366 hfsextreadextent fs/hfs/extent.c:196 [inline] hfsgetblock+0x92d/0x1620 fs/hfs/extent.c:366 blockreadfullfolio+0x4ff/0x11b0 fs/buffer.c:2271 hfsreadfolio+0x55/0x60 fs/hfs/inode.c:39 filemapreadfolio+0x148/0x4f0 mm/filemap.c:2426 doreadcachefolio+0x7c8/0xd90 mm/filemap.c:3553 doreadcachepage mm/filemap.c:3595 [inline] readcachepage+0xfb/0x2f0 mm/filemap.c:3604 readmappingpage include/linux/pagemap.h:755 [inline] hfsbtreeopen+0x928/0x1ae0 fs/hfs/btree.c:78 hfsmdbget+0x260c/0x3000 fs/hfs/mdb.c:204 hfsfillsuper+0x1fb1/0x2790 fs/hfs/super.c:406 mountbdev+0x628/0x920 fs/super.c:1359 hfsmount+0xcd/0xe0 fs/hfs/super.c:456 legacygettree+0x167/0x2e0 fs/fscontext.c:610 vfsgettree+0xdc/0x5d0 fs/super.c:1489 donewmount+0x7a9/0x16f0 fs/namespace.c:3145 pathmount+0xf98/0x26a0 fs/namespace.c:3475 domount fs/namespace.c:3488 [inline] _dosysmount fs/namespace.c:3697 [inline] _sesysmount+0x919/0x9e0 fs/namespace.c:3674 _ia32sysmount+0x15b/0x1b0 fs/namespace.c:3674 dosyscall32irqson arch/x86/entry/common.c:112 [inline] _dofastsyscall32+0xa2/0x100 arch/x86/entry/common.c:178 dofastsyscall32+0x37/0x80 arch/x86/entry/common.c:203 doSYSENTER32+0x1f/0x30 arch/x86/entry/common.c:246 entrySYSENTERcompatafterhwframe+0x70/0x82

Uninit was created at: allocpages+0x9a6/0xe00 mm/pagealloc.c:4590 _allocpagesnode include/linux/gfp.h:238 [inline] allocpagesnode include/linux/gfp.h:261 [inline] allocslabpage mm/slub.c:2190 [inline] allocateslab mm/slub.c:2354 [inline] newslab+0x2d7/0x1400 mm/slub.c:2407 _slaballoc+0x16b5/0x3970 mm/slub.c:3540 _slaballoc mm/slub.c:3625 [inline] _slaballocnode mm/slub.c:3678 [inline] slaballocnode mm/slub.c:3850 [inline] kmemcachealloclru+0x64d/0xb30 mm/slub.c:3879 allocinodesb include/linux/fs.h:3018 [inline] hfsallocinode+0x5a/0xc0 fs/hfs/super.c:165 allocinode+0x83/0x440 fs/inode.c:260 newinodepseudo fs/inode.c:1005 [inline] newinode+0x38/0x4f0 fs/inode.c:1031 hfsnewinode+0x61/0x1010 fs/hfs/inode.c:186 hfsmkdir+0x54/0x250 fs/hfs/dir.c:228 vfsmkdir+0x49a/0x700 fs/namei.c:4126 domkdirat+0x529/0x810 fs/namei.c:4149 _dosysmkdirat fs/namei.c:4164 [inline] _sesysmkdirat fs/namei.c:4162 [inline] _x64sysmkdirat+0xc8/0x120 fs/namei.c:4162 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

It missed to initialize .tzsecondswest, .cachedstart and .cachedblocks fields in struct hfsinodeinfo after hfsalloc_inode(), fix it.(CVE-2024-42311)

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

media: venus: fix use after free in vdec_close

There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst.

Fix it by cancelling the work in vdec_close.(CVE-2024-42313)

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

ipvs: properly dereference pe in ipvsadd_service

Use pe directly to resolve sparse warning:

net/netfilter/ipvs/ipvsctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)

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

PCI: keystone: Fix NULL pointer dereference in case of DT error in kspciesetuprcapp_regs()

If IORESOURCEMEM is not provided in Device Tree due to any error, resourcelistfirsttype() will return NULL and pciparserequestofpci_ranges() will just emit a warning.

This will cause a NULL pointer dereference. Fix this bug by adding NULL return check.

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

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

ext4: fix infinite loop when replaying fast_commit

When doing fastcommit replay an infinite loop may occur due to an uninitialized extentstatus struct. ext4extdetermineinserthole() does not detect the replay and calls ext4esfindextentrange(), which will return immediately without initializing the 'es' variable.

Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039.

This commit fixes this issue by unconditionally initializing the structure in function ext4esfindextentrange().

Thanks to Zhang Yi, for figuring out the real problem!(CVE-2024-43828)

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

leds: trigger: Unregister sysfs attributes before calling deactivate()

Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback.

Calling deviceremovegroups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data.

Move the deviceremovegroups() call to before deactivate() to close this race window.

This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling deviceaddgroups().(CVE-2024-43830)

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

media: mediatek: vcodec: Handle invalid decoder vsi

Handle an invalid decoder vsi in vpudecinit to ensure the decoder vsi is valid for future use.(CVE-2024-43831)

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:

bpf, arm64: Fix trampoline for BPFTRAMPFCALLORIG

When BPFTRAMPFCALLORIG is set, the trampoline calls _bpftrampenter() and _bpftrampexit() functions, passing them the struct bpftrampimage *im pointer as an argument in R0.

The trampoline generation code uses emitaddrmovi64() to emit instructions for moving the bpftrampimage address into R0, but emitaddrmovi64() assumes the address to be in the vmalloc() space and uses only 48 bits. Because bpftrampimage is allocated using kzalloc(), its address can use more than 48-bits, in this case the trampoline will pass an invalid address to _bpftramp_enter/exit() causing a kernel crash.

Fix this by using emita64movi64() in place of emitaddrmovi64() as it can work with addresses that are greater than 48-bits.(CVE-2024-43840)

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

remoteproc: imx_rproc: Skip over memory region when node value is NULL

In imxrprocaddrinit() "nph = ofcountphandlewithargs()" just counts number of phandles. But phandles may be empty. So ofparse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixed title to fit within the prescribed 70-75 charcters

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

memcg: protect concurrent access to memcgroupidr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the memcgroupidr, the idralloc() and idrreplace() happen within css callback and thus are protected through cgroupmutex from concurrent modifications. However idrremove() for memcgroupidr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.

We have been seeing listlru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of listlru code including listlruadd(), listlrudel() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the superblock's listlru didn't have listlruone for the memcg of that object. The initial suspicions were either the object is not allocated through kmemcachealloclru() or somehow memcglistlrualloc() failed to allocate listlruone() for a memcg but returned success. No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id is not present in memcgroupidr and in some cases multiple valid memcgs have same id and memcgroupidr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idrremove() calls or race between idralloc()/idrreplace() and idrremove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup listlrus on the system for all of them. Later access from other memcgs to the listlru cause crashes due to missing listlruone.(CVE-2024-43892)

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

serial: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baudbase can result in uartclk being zero, which will result in a divide by zero error in uartgetdivisor(). The check for uartclk being zero in uartset_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set.

Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uartgetdivisor (drivers/tty/serial/serialcore.c:580) Call Trace: <TASK> serial8250getdivisor (drivers/tty/serial/8250/8250port.c:2576 drivers/tty/serial/8250/8250port.c:2589) serial8250dosettermios (drivers/tty/serial/8250/8250port.c:502 drivers/tty/serial/8250/8250port.c:2741) serial8250settermios (drivers/tty/serial/8250/8250port.c:2862) uartchangelinesettings (./include/linux/spinlock.h:376 ./include/linux/serialcore.h:608 drivers/tty/serial/serialcore.c:222) uartportstartup (drivers/tty/serial/serialcore.c:342) uartstartup (drivers/tty/serial/serialcore.c:368) uartsetinfo (drivers/tty/serial/serialcore.c:1034) uartsetinfouser (drivers/tty/serial/serialcore.c:1059) ttysetserial (drivers/tty/ttyio.c:2637) ttyioctl (drivers/tty/ttyio.c:2647 drivers/tty/ttyio.c:2791) _x64sysioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Rule: add(CVE-2024-43893)

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

drm/client: fix null pointer dereference in drmclientmodeset_probe

In drmclientmodesetprobe(), the return value of drmmodeduplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drmmode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)

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

gpio: prevent potential speculation leaks in gpiodeviceget_desc()

Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpioioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpiodevicegetdesc().

This change ensures that the offset is sanitized by using arrayindexnospec() to mitigate any possibility of speculative information leaks.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.(CVE-2024-44931)

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

driver core: Fix uevent_show() vs driver detach race

ueventshow() wants to de-reference dev->driver->name. There is no clean way for a device attribute to de-reference dev->driver unless that attribute is defined via (struct devicedriver).devgroups. Instead, the anti-pattern of taking the devicelock() in the attribute handler risks deadlocks with code paths that remove device attributes while holding the lock.

This deadlock is typically invisible to lockdep given the devicelock() is marked lockdepsetnovalidateclass(), but some subsystems allocate a local lockdep key for @dev->mutex to reveal reports of the form:

====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G OE N

modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: _kernfsremove+0xde/0x220

but task is already holding lock: ffff8c22016e88f8 (&cxlrootkey){+.+.}-{3:3}, at: devicereleasedriver_internal+0x39/0x210

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&cxlrootkey){+.+.}-{3:3}: _mutexlock+0x99/0xc30 ueventshow+0xac/0x130 devattrshow+0x18/0x40 sysfskfseqshow+0xac/0xf0 seqreaditer+0x110/0x450 vfsread+0x25b/0x340 ksysread+0x67/0xf0 dosyscall64+0x75/0x190 entrySYSCALL64afterhwframe+0x76/0x7e

-> #0 (kn->active#6){++++}-{0:0}: _lockacquire+0x121a/0x1fa0 lockacquire+0xd6/0x2e0 kernfsdrain+0x1e9/0x200 _kernfsremove+0xde/0x220 kernfsremovebynamens+0x5e/0xa0 devicedel+0x168/0x410 deviceunregister+0x13/0x60 devresreleaseall+0xb8/0x110 deviceunbindcleanup+0xe/0x70 devicereleasedriverinternal+0x1c7/0x210 driverdetach+0x47/0x90 busremovedriver+0x6c/0xf0 cxlacpiexit+0xc/0x11 [cxlacpi] _dosysdeletemodule.isra.0+0x181/0x260 dosyscall64+0x75/0x190 entrySYSCALL64after_hwframe+0x76/0x7e

The observation though is that driver objects are typically much longer lived than device objects. It is reasonable to perform lockless de-reference of a @driver pointer even if it is racing detach from a device. Given the infrequency of driver unregistration, use synchronizercu() in moduleremovedriver() to close any potential races. It is potentially overkill to suffer synchronizercu() just to handle the rare module removal racing uevent_show() event.

Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].(CVE-2024-44952)

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

bonding: fix null pointer deref in bondipsecoffload_ok

We must check if there is an active slave before dereferencing the pointer.(CVE-2024-44990)

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

netfilter: flowtable: initialise extack before use

Fix missing initialisation of extack in flow offload.(CVE-2024-45018)

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

nfc: pn533: Add poll mod list filling check

In case of improtocols value is 1 and tmprotocols value is 0 this combination successfully passes the check 'if (!improtocols && !tmprotocols)' in the nfcstartpoll(). But then after pn533pollcreatemodlist() call in pn533startpoll() poll mod list will remain empty and dev->pollmodcount will remain 0 which lead to division by zero.

Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFCCMDSTARTPOLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->pollmodcount is not incremented inside pn533pollcreatemodlist(), thus leading to division by zero. Call trace looks like: nfcgenlstartpoll() nfcstartpoll() ->startpoll() pn533start_poll()

Add poll mod list filling check.

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

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

soc: qcom: cmd-db: Map shared memory as WC, not WB

Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone.

The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings.

Changing the mapping of cmd-db memory from MEMREMAPWB to MEMREMAPWT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC.

I tested this on SA8155P with Xen.(CVE-2024-46689)

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

usb: typec: ucsi: Move unregister out of atomic section

Commit '9329933699b3 ("soc: qcom: pmicglink: Make client-lock non-sleeping")' moved the pmicglink client list under a spinlock, as it is accessed by the rpmsg/glink callback, which in turn is invoked from IRQ context.

This means that ucsi_unregister() is now called from atomic context, which isn't feasible as it's expecting a sleepable context. An effort is under way to get GLINK to invoke its callbacks in a sleepable context, but until then lets schedule the unregistration.

A side effect of this is that ucsiunregister() can now happen after the remote processor, and thereby the communication link with it, is gone. pmicglink_send() is amended with a check to avoid the resulting NULL pointer dereference. This does however result in the user being informed about this error by the following entry in the kernel log:

ucsiglink.pmicglinkucsi pmicglink.ucsi.0: failed to send UCSI write request: -5(CVE-2024-46691)

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

drm/vmwgfx: Fix prime with external buffers

Make sure that for external buffers mapping goes through the dma_buf interface instead of trying to access pages directly.

External buffers might not provide direct access to readable/writable pages so to make sure the bo's created from external dmabufs can be read dmabuf interface has to be used.

Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't trigger this due to the fact that virtual machines will not have multiple GPUs but it enables better test coverage in IGT.(CVE-2024-46709)

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

dmaengine: altera-msgdma: properly free descriptor in msgdmafreedescriptor

Remove listdel call in msgdmachandesccleanup, this should be the role of msgdmafreedescriptor. In consequence replace listaddtail with listmovetail in msgdmafreedescriptor.

This fixes the path: msgdmafreechanresources -> msgdmafreedescriptors -> msgdmafreedesclist -> msgdmafreedescriptor

which does not correctly free the descriptors as first nodes were not removed from the list.(CVE-2024-46716)

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

drm/amd/display: Ensure index calculation will not overflow

[WHY & HOW] Make sure vmid0p72idx, vnom0p8idx and vmax0p9_idx calculation will never overflow and exceess array size.

This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)

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

bpf: Remove tstrun from lwtseg6localprogops.

The syzbot reported that the lwtseg6 related BPF ops can be invoked via bpftestrun() without without entering inputactionendbpf() first.

Martin KaFai Lau said that self test for BPFPROGTYPELWTSEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6bpfsrh_states::srh is never assigned in the self test case but each BPF function expects it.

Remove testrun for BPFPROGTYPELWT_SEG6LOCAL.(CVE-2024-46754)

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

ksmbd: unset the binding mark of a reused connection

Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generatepreauthhash() will not set sess->PreauthHashValue and it will be NULL. It is used as a material to create an encryption key in ksmbdgensmb311encryptionkey. ->PreauthHashValue cause null pointer dereference error from cryptoshash_update().

BUG: kernel NULL pointer dereference, address: 0000000000000000

PF: supervisor read access in kernel mode

PF: error_code(0x0000) - not-present page

PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handleksmbdwork [ksmbd] RIP: 0010:libsha256basedoupdate.isra.0+0x11e/0x1d0 [sha256ssse3] <TASK> ? showregs+0x6d/0x80 ? _die+0x24/0x80 ? pagefaultoops+0x99/0x1b0 ? douseraddrfault+0x2ee/0x6b0 ? excpagefault+0x83/0x1b0 ? asmexcpagefault+0x27/0x30 ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] ? libsha256basedoupdate.isra.0+0x11e/0x1d0 [sha256ssse3] ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] _sha256update+0x77/0xa0 [sha256ssse3] sha256avx2update+0x15/0x30 [sha256ssse3] cryptoshashupdate+0x1e/0x40 hmacupdate+0x12/0x20 cryptoshashupdate+0x1e/0x40 generatekey+0x234/0x380 [ksmbd] generatesmb3encryptionkey+0x40/0x1c0 [ksmbd] ksmbdgensmb311encryptionkey+0x72/0xa0 [ksmbd] ntlmauthenticate.isra.0+0x423/0x5d0 [ksmbd] smb2sesssetup+0x952/0xaa0 [ksmbd] _processrequest+0xa3/0x1d0 [ksmbd] _handleksmbdwork+0x1c4/0x2f0 [ksmbd] handleksmbdwork+0x2d/0xa0 [ksmbd] processonework+0x16c/0x350 workerthread+0x306/0x440 ? _pfxworkerthread+0x10/0x10 kthread+0xef/0x120 ? _pfxkthread+0x10/0x10 retfromfork+0x44/0x70 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1b/0x30 </TASK>(CVE-2024-46795)

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

drm/amdgpu: fix the waring dereferencing hive

Check the amdgpuhiveinfo *hive that maybe is NULL.(CVE-2024-46805)

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

drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ

Make sure the connector is fully initialized before signalling any HPD events via drmkmshelperhotplugevent(), otherwise this may lead to NULL pointer dereference.(CVE-2024-46810)

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

drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6

[Why] Coverity reports OVERRUN warning. Should abort amdgpu_dm initialize.

[How] Return failure to amdgpudminit.(CVE-2024-46817)

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

drm/amdgpu: the warning dereferencing obj for nbiov74

if ras_manager obj null, don't print NBIO err data(CVE-2024-46819)

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

drm/amd/pm: Fix negative array index read

Avoid using the negative values for clk_idex as an index into an array pptable->DpmDescriptor.

V2: fix clk_index return check (Tim Huang)(CVE-2024-46821)

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

arm64: acpi: Harden getcpuforacpiid() against missing CPU entry

In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed.

If an MPIDR check fails in acpimapgiccpuinterface() it is possible for the entry in cpumadtgicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility.(CVE-2024-46822)

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

ELF: fix kernel.randomizevaspace double read

ELF loader uses "randomizevaspace" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.

Issue exactly one load for consistent value across one exec.(CVE-2024-46826)

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

KVM: x86: Acquire kvm->srcu when handling KVMSETVCPU_EVENTS

Grab kvm->srcu when processing KVMSETVCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory.

Note, kvmvcpuioctlx86setvcpuevents() can also be called from KVMRUN via syncregs(), which already holds SRCU. I.e. trying to precisely use kvmvcpusrcureadlock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVMSETVCPU_EVENTS.

============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted

include/linux/kvmhost.h:1027 suspicious rcudereference_check() usage!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvmvcpu_ioctl+0x7d/0x970 [kvm]

stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x7f/0x90 lockdeprcususpicious+0x13f/0x1a0 kvmvcpugfntomemslot+0x168/0x190 [kvm] kvmvcpureadguest+0x3e/0x90 [kvm] nestedvmxloadmsr+0x6b/0x1d0 [kvmintel] loadvmcs12hoststate+0x432/0xb40 [kvmintel] vmxleavenested+0x30/0x40 [kvmintel] kvmvcpuioctlx86setvcpuevents+0x15d/0x2b0 [kvm] kvmarchvcpuioctl+0x1107/0x1750 [kvm] ? markheldlocks+0x49/0x70 ? kvmvcpuioctl+0x7d/0x970 [kvm] ? kvmvcpuioctl+0x497/0x970 [kvm] kvmvcpuioctl+0x497/0x970 [kvm] ? lockacquire+0xba/0x2d0 ? findheldlock+0x2b/0x80 ? douseraddrfault+0x40c/0x6f0 ? lockrelease+0xb7/0x270 _x64sysioctl+0x82/0xb0 dosyscall64+0x6c/0x170 entrySYSCALL64after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>(CVE-2024-46830)

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

usb: gadget: aspeed_udc: validate endpoint index for ast udc

We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array.

Found by static analysis.(CVE-2024-46836)

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

userfaultfd: don't BUG_ON() if khugepaged yanks our page table

Since khugepaged was changed to allow retracting page tables in file mappings without holding the mmap lock, these BUG_ON()s are wrong - get rid of them.

We could also remove the preceding "if (unlikely(...))" block, but then we could reach pteoffsetmap_lock() with transhuge pages not just for file mappings but also for anonymous mappings - which would probably be fine but I think is not necessarily expected.(CVE-2024-46838)

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

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUGON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walkdownproc we also BUGON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In dowalkdown() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walkupproc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.(CVE-2024-46840)

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

net: dpaa: Pad packets to ETH_ZLEN

When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running

$ ping -s 11 destination(CVE-2024-46854)

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

netfilter: nft_socket: fix sk refcount leaks

We must put 'sk' reference before returning.(CVE-2024-46855)

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

mptcp: pm: Fix uaf in _timerdelete_sync

There are two paths to access mptcppmdeladdtimer, result in a race condition:

 CPU1               CPU2
 ====                               ====
 net_rx_action
 napi_poll                          netlink_sendmsg
 __napi_poll                        netlink_unicast
 process_backlog                    netlink_unicast_kernel
 __netif_receive_skb                genl_rcv
 __netif_receive_skb_one_core       netlink_rcv_skb
 NF_HOOK                            genl_rcv_msg
 ip_local_deliver_finish            genl_family_rcv_msg
 ip_protocol_deliver_rcu            genl_family_rcv_msg_doit
 tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit
 tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list
 tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows
 tcp_data_queue                     remove_anno_list_by_saddr
 mptcp_incoming_options             mptcp_pm_del_add_timer
 mptcp_pm_del_add_timer             kfree(entry)

In removeannolistbysaddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcppmdeladdtimer(running on CPU1).

Keeping a reference to addtimer inside the lock, and calling skstoptimersync() with this reference, instead of "entry->add_timer".

Move listdel(&entry->list) to mptcppmdeladd_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.(CVE-2024-46858)

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

platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses

The panasonic laptop code in various places uses the SINF array with index values of 0 - SINFCURBRIGHT(0x0d) without checking that the SINF array is big enough.

Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute.

Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller.

For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these.(CVE-2024-46859)

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

crypto: stm32/cryp - call finalize with bh disabled

The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.(CVE-2024-47658)

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

i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup

Definitely condition dmagetcachealignment * defined value > 256 during driver initialization is not reason to BUGON(). Turn that to graceful error out with -EINVAL.(CVE-2024-47665)

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

nilfs2: fix state management in error path of log writing function

After commit a694291a6211 ("nilfs2: separate wait function from nilfssegctorwrite") was applied, the log writing function nilfssegctordo_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.

First, if nilfssegctorbeginconstruction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfssegctorabortconstruction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncateinodepagesfinal(), which is called via nilfsevict_inode() when an inode is evicted from memory, will hang.

Second, the NILFSICOLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFSICOLLECTED set are erroneously removed from the "scdirtyfiles" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.

Fix these issues by uniformly calling nilfssegctorabortconstruction() on failure of each step in the loop in nilfssegctordoconstruct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfsredirtyinodes() to ensure that the NILFSICOLLECTED flag is cleared.(CVE-2024-47669)

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

USB: usbtmc: prevent kernel-usb-infoleak

The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.(CVE-2024-47671)

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

wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead

There is a WARNING in iwltranswaittxqueues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead.

Don't call iwltranswaittxqueues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running.

edit commit message

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpfuprobemultilinkattach() If bpflinkprime() fails, bpfuprobemultilinkattach() goes to the errorfree label and frees the array of bpfuprobe's without calling bpfuprobeunregister(). This leaks bpfuprobe->uprobe and worse, this frees bpfuprobe->consumer without removing it from the uprobe->consumers list.(CVE-2024-47675)

In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix alidrwpmu driver interrupt status clearing The alibabauncorepmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.(CVE-2024-47731)

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEKDATA or SEEKHOLE and ends up at file.c:finddesiredextent() while holding a read lock on the inode; 3) At the start of finddesiredextent(), it extracts the file's privatedata pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEKDATA or SEEKHOLE, locks the inode in shared mode and enters file.c:finddesiredextent(), where it also extracts file->privatedata into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfsfileprivate::llseekcachedstate), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:countrangebits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.(CVE-2024-47741)

Database specific

{
    "severity": "Critical"
}

References

Affected packages

openEuler:24.03-LTS / kernel

Package

Name: kernel
Purl: pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0Unknown introduced version / All previous versions are affected

Fixed

6.6.0-47.0.0.52.oe2403

Ecosystem specific

{
    "x86_64": [
        "bpftool-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "bpftool-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-debugsource-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-devel-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-headers-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-source-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-tools-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-tools-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "kernel-tools-devel-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "perf-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "perf-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "python3-perf-6.6.0-47.0.0.52.oe2403.x86_64.rpm",
        "python3-perf-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm"
    ],
    "aarch64": [
        "bpftool-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "bpftool-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-debugsource-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-devel-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-headers-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-source-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-tools-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-tools-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "kernel-tools-devel-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "perf-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "perf-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "python3-perf-6.6.0-47.0.0.52.oe2403.aarch64.rpm",
        "python3-perf-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm"
    ],
    "src": [
        "kernel-6.6.0-47.0.0.52.oe2403.src.rpm"
    ]
}