The Linux Kernel, the operating system core itself.

Security Fix(es):

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

firmware: arm_scmi: Harden accesses to the reset domains

Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave.

Add an internal consistency check before any such domains descriptors accesses.(CVE-2022-48655)

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

netfilter: nftables: exthdr: fix 4-byte stack OOB write

If priv->len is a multiple of 4, then dst[len / 4] can write past the destination array which leads to stack corruption.

This construct is necessary to clean the remainder of the register in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does.

The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added.

Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)

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

media: rc: bpf attach/detach requires write permission

Note that bpf attach/detach also requires CAPNETADMIN.(CVE-2023-52642)

A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmdcfgpkts() function improperly updates the refcnt on struct net_device, and a use-after-free can be triggered by racing between the free on the struct and the access through the skbtxq global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)

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

blk-mq: fix IO hang from sbitmap wakeup race

In blkmqmarktagwait(), _addwaitqueue() may be re-ordered with the following blkmqgetdriver_tag() in case of getting driver tag failure.

Then in _sbitmapqueuewakeup(), waitqueueactive() may not observe the added waiter in blkmqmarktagwait() and wake up nothing, meantime blkmqmarktag_wait() can't get driver tag successfully.

This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop.

modprobe -r scsi_debug
modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4
dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`
fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \
        --runtime=100 --numjobs=40 --time_based --name=test \
        --ioengine=libaio

Fix the issue by adding one explicit barrier in blkmqmarktagwait(), which is just fine in case of running out of tag.(CVE-2024-26671)

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

fs,hugetlb: fix NULL pointer dereference in hugetlbsfillsuper

When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfsfillsuper() caused by assigning NULL to ctx->hstate in hugetlbfsparseparam() when the requested pagesize is non valid.

E.g: Taking the following steps:

 fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);
 fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);
 fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);

Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error:

... ... case Optpagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { prerr("Unsupported page size %lu MB\n", ps / SZ_1M); return -EINVAL; } return 0; ... ...

This is a problem because later on, we will dereference ctxt->hstate in hugetlbfsfillsuper()

... ... sb->sblocksize = hugepage_size(ctx->hstate); ... ...

Causing below Oops.

Fix this by replacing cxt->hstate value only when then pagesize is known to be valid.

kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: errorcode(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfsfillsuper+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel: <TASK> kernel: ? _diebody+0x1a/0x60 kernel: ? pagefaultoops+0x16f/0x4a0 kernel: ? searchbpfextables+0x65/0x70 kernel: ? fixupexception+0x22/0x310 kernel: ? excpagefault+0x69/0x150 kernel: ? asmexcpagefault+0x22/0x30 kernel: ? _pfxhugetlbfsfillsuper+0x10/0x10 kernel: ? hugetlbfsfillsuper+0xb4/0x1a0 kernel: ? hugetlbfsfillsuper+0x28/0x1a0 kernel: ? _pfxhugetlbfsfillsuper+0x10/0x10 kernel: vfsgetsuper+0x40/0xa0 kernel: ? _pfxbpflsmcapable+0x10/0x10 kernel: vfsgettree+0x25/0xd0 kernel: vfscmdcreate+0x64/0xe0 kernel: _x64sysfsconfig+0x395/0x410 kernel: dosyscall64+0x80/0x160 kernel: ? syscallexittousermode+0x82/0x240 kernel: ? dosyscall64+0x8d/0x160 kernel: ? syscallexittousermode+0x82/0x240 kernel: ? dosyscall64+0x8d/0x160 kernel: ? excpagefault+0x69/0x150 kernel: entrySYSCALL64afterhwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 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 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff ---truncated---(CVE-2024-26688)

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

btrfs: fix double free of anonymous device after snapshot creation failure

When creating a snapshot we may do a double free of an anonymous device in case there's an error committing the transaction. The second free may result in freeing an anonymous device number that was allocated by some other subsystem in the kernel or another btrfs filesystem.

The steps that lead to this:

1) At ioctl.c:createsnapshot() we allocate an anonymous device number and assign it to pendingsnapshot->anon_dev;

2) Then we call btrfscommittransaction() and end up at transaction.c:creatependingsnapshot();

3) There we call btrfsgetnewfsroot() and pass it the anonymous device number stored in pendingsnapshot->anondev;

4) btrfsgetnewfsroot() frees that anonymous device number because btrfslookupfs_root() returned a root - someone else did a lookup of the new root already, which could some task doing backref walking;

5) After that some error happens in the transaction commit path, and at ioctl.c:createsnapshot() we jump to the 'fail' label, and after that we free again the same anonymous device number, which in the meanwhile may have been reallocated somewhere else, because pendingsnapshot->anon_dev still has the same value as in step 1.

Recently syzbot ran into this and reported the following trace:

------------[ cut here ]------------ idafree called for id=51 which is not allocated. WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 idafree+0x370/0x420 lib/idr.c:525 Modules linked in: CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 RIP: 0010:idafree+0x370/0x420 lib/idr.c:525 Code: 10 42 80 3c 28 (...) RSP: 0018:ffffc90015a67300 EFLAGS: 00010246 RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000 RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4 R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246 R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246 FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0 Call Trace: <TASK> btrfsgetrootref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346 creatependingsnapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837 creatependingsnapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931 btrfscommittransaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404 createsnapshot+0x507/0x880 fs/btrfs/ioctl.c:848 btrfsmksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998 btrfsmksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044 _btrfsioctlsnapcreate+0x387/0x4b0 fs/btrfs/ioctl.c:1306 btrfsioctlsnapcreatev2+0x1ca/0x400 fs/btrfs/ioctl.c:1393 btrfsioctl+0xa74/0xd40 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:871 [inline] _sesysioctl+0xfe/0x170 fs/ioctl.c:857 dosyscall64+0xfb/0x240 entrySYSCALL64afterhwframe+0x6f/0x77 RIP: 0033:0x7fca3e67dda9 Code: 28 00 00 00 (...) RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9 RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658 </TASK>

Where we get an explicit message where we attempt to free an anonymous device number that is not currently allocated. It happens in a different code path from the example below, at btrfsgetroot_ref(), so this change may not fix the case triggered by sy ---truncated---(CVE-2024-26792)

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

amdkfd: use calloc instead of kzalloc to avoid integer overflow

This uses calloc instead of doing the multiplication which might overflow.(CVE-2024-26817)

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

IB/hfi1: Fix a memleak in initcreditreturn

When dmaalloccoherent fails to allocate dd->crbase[i].va, initcreditreturn should deallocate dd->crbase and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.(CVE-2024-26839)

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

cachefiles: fix memory leak in cachefilesaddcache()

The following memory leak was reported after unbinding /dev/cachefiles:

================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmemcachealloc+0x2d5/0x370 [<ffffffff8e917f86>] preparecreds+0x26/0x2e0 [<ffffffffc002eeef>] cachefilesdeterminecachesecurity+0x1f/0x120 [<ffffffffc00243ec>] cachefilesaddcache+0x13c/0x3a0 [<ffffffffc0025216>] cachefilesdaemonwrite+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfswrite+0xcb/0x520 [<ffffffff8ebc5069>] ksyswrite+0x69/0xf0 [<ffffffff8f6d4662>] dosyscall64+0x72/0x140

[<ffffffff8f8000aa>] entrySYSCALL64afterhwframe+0x6e/0x76

Put the reference count of cachecred in cachefilesdaemonunbind() to fix the problem. And also put cachecred in cachefilesaddcache() error branch to avoid memory leaks.(CVE-2024-26840)

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

efi: runtime: Fix potential overflow of soft-reserved region size

md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region.(CVE-2024-26843)

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

net: ice: Fix potential NULL pointer dereference in icebridgesetlink()

The function icebridgesetlink() may encounter a NULL pointer dereference if nlmsgfindattr() returns NULL and brspec is dereferenced subsequently in nlaforeachnested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)

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

media: pvrusb2: fix uaf in pvr2contextset_notify

[Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2contextset_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26

CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usbhubwq hubevent Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 pvr2contextsetnotify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2contextnotify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2contextdisconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272

Freed by task 906: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] _kasanslabfree+0x106/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inline] slabfree mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2contextcheck drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2contextthreadfunc+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158

[Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue.

[Fix] Place the disconnectflag assignment operation after all code in pvr2context_disconnect() to avoid this issue.(CVE-2024-26875)

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

quota: Fix potential NULL pointer dereference

Below race may cause NULL pointer dereference

P1 P2 dquotfreeinode quotaoff dropdquotref removedquotref dquots = idquot(inode) dquots = idquot(inode) srcureadlock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spinlock(&dquots[cnt]->dqdqblock) (3) ....

If dquotfreeinode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered.

So let's fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)

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

firmware: arm_scmi: Fix double free in SMC transport cleanup path

When the generic SCMI code tears down a channel, it calls the chanfree callback function, defined by each transport. Since multiple protocols might share the same transportinfo member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time:

| scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
| arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
| arm-scmi firmware:scmi: unable to communicate with SCMI
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
| Mem abort info:
|   ESR = 0x0000000096000004
|   EC = 0x25: DABT (current EL), IL = 32 bits
|   SET = 0, FnV = 0
|   EA = 0, S1PTW = 0
|   FSC = 0x04: level 0 translation fault
| Data abort info:
|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
| [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in:
| CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
| Hardware name: FVP Base RevC (DT)
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : smc_chan_free+0x3c/0x6c
| lr : smc_chan_free+0x3c/0x6c
| Call trace:
|  smc_chan_free+0x3c/0x6c
|  idr_for_each+0x68/0xf8
|  scmi_cleanup_channels.isra.0+0x2c/0x58
|  scmi_probe+0x434/0x734
|  platform_probe+0x68/0xd8
|  really_probe+0x110/0x27c
|  __driver_probe_device+0x78/0x12c
|  driver_probe_device+0x3c/0x118
|  __driver_attach+0x74/0x128
|  bus_for_each_dev+0x78/0xe0
|  driver_attach+0x24/0x30
|  bus_add_driver+0xe4/0x1e8
|  driver_register+0x60/0x128
|  __platform_driver_register+0x28/0x34
|  scmi_driver_init+0x84/0xc0
|  do_one_initcall+0x78/0x33c
|  kernel_init_freeable+0x2b8/0x51c
|  kernel_init+0x24/0x130
|  ret_from_fork+0x10/0x20
| Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
| ---[ end trace 0000000000000000 ]---

Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation.

This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)

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

aoe: fix the potential use-after-free problem in aoecmdcfgpkts

This patch is against CVE-2023-6270. The description of cve is:

A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmdcfgpkts() function improperly updates the refcnt on struct net_device, and a use-after-free can be triggered by racing between the free on the struct and the access through the skbtxq global queue. This could lead to a denial of service condition or potential code execution.

In aoecmdcfgpkts(), it always calls devput(ifp) when skb initial code is finished. But the netdevice ifp will still be used in later tx()->devqueuexmit() in kthread. Which means that the devput(ifp) should NOT be called in the success path of skb initial code in aoecmdcfgpkts(). Otherwise tx() may run into use-after-free because the netdevice is freed.

This patch removed the devput(ifp) in the success path in aoecmdcfgpkts(), and added devput() after skb xmit in tx().(CVE-2024-26898)