The Linux Kernel, the operating system core itself.

Security Fix(es):

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

dmaengine: idxd: Prevent use after free on completion memory

On driver unload any pending descriptors are flushed at the time the interrupt is freed: idxddmaenginedrvremove() -> drvdisablewq() -> idxdwqfreeirq() -> idxdflushpending_descs().

If there are any descriptors present that need to be flushed this flow triggers a "not present" page fault as below:

BUG: unable to handle page fault for address: ff391c97c70c9040 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page

The address that triggers the fault is the address of the descriptor that was freed moments earlier via: drvdisablewq()->idxdwqfree_resources()

Fix the use after free by freeing the descriptors after any possible usage. This is done after idxdwqreset() to ensure that the memory remains accessible during possible completion writes by the device.(CVE-2022-48867)

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

drm/vmwgfx: Remove rcu locks from user resources

User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources.

Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources.(CVE-2022-48887)

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

btrfs: do not start relocation until in progress drops are done

We hit a bug with a recovering relocation on mount for one of our file systems in production. I reproduced this locally by injecting errors into snapshot delete with balance running at the same time. This presented as an error while looking up an extent item

WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookupinlineextentbackref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookupinlineextentbackref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: <TASK> insertinlineextentbackref+0x46/0xd0 _btrfsincextentref.isra.0+0x5f/0x200 ? btrfsmergedelayedrefs+0x164/0x190 _btrfsrundelayedrefs+0x561/0xfa0 ? btrfssearchslot+0x7b4/0xb30 ? btrfsupdateroot+0x1a9/0x2c0 btrfsrundelayedrefs+0x73/0x1f0 ? btrfsupdateroot+0x1a9/0x2c0 btrfscommittransaction+0x50/0xa50 ? btrfsupdaterelocroot+0x122/0x220 preparetomerge+0x29f/0x320 relocateblockgroup+0x2b8/0x550 btrfsrelocateblockgroup+0x1a6/0x350 btrfsrelocatechunk+0x27/0xe0 btrfsbalance+0x777/0xe60 balancekthread+0x35/0x50 ? btrfsbalance+0xe60/0xe60 kthread+0x16b/0x190 ? setkthreadstruct+0x40/0x40 retfromfork+0x22/0x30 </TASK>

Normally snapshot deletion and relocation are excluded from running at the same time by the fsinfo->cleanermutex. However if we had a pending balance waiting to get the ->cleaner_mutex, and a snapshot deletion was running, and then the box crashed, we would come up in a state where we have a half deleted snapshot.

Again, in the normal case the snapshot deletion needs to complete before relocation can start, but in this case relocation could very well start before the snapshot deletion completes, as we simply add the root to the dead roots list and wait for the next time the cleaner runs to clean up the snapshot.

Fix this by setting a bit on the fsinfo if we have any DEADROOT's that had a pending dropprogress key. If they do then we know we were in the middle of the drop operation and set a flag on the fsinfo. Then balance can wait until this flag is cleared to start up again.

If there are DEADROOT's that don't have a dropprogress set then we're safe to start balance right away as we'll be properly protected by the cleaner_mutex.(CVE-2022-48901)

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

btrfs: do not WARN_ON() if we have PageError set

Whenever we do any extent buffer operations we call assertebpage_uptodate() to complain loudly if we're operating on an non-uptodate page. Our overnight tests caught this warning earlier this week

WARNING: CPU: 1 PID: 553508 at fs/btrfs/extentio.c:6849 assertebpageuptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfsworkhelper RIP: 0010:assertebpage_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace:

extentbuffertestbit+0x3f/0x70 freespacetestbit+0xa6/0xc0 loadfreespacetree+0x1f6/0x470 cachingthread+0x454/0x630 ? rcureadlockschedheld+0x12/0x60 ? rcureadlockschedheld+0x12/0x60 ? rcureadlockschedheld+0x12/0x60 ? lockrelease+0x1f0/0x2d0 btrfsworkhelper+0xf2/0x3e0 ? lockrelease+0x1f0/0x2d0 ? finishtaskswitch.isra.0+0xf9/0x3a0 processonework+0x26d/0x580 ? processonework+0x580/0x580 workerthread+0x55/0x3b0 ? processonework+0x580/0x580 kthread+0xf0/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30

This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it"), however all that fix did was keep us from finding extent buffers after a failed writeout. It didn't keep us from continuing to use a buffer that we already had found.

In this case we're searching the commit root to cache the block group, so we can start committing the transaction and switch the commit root and then start writing. After the switch we can look up an extent buffer that hasn't been written yet and start processing that block group. Then we fail to write that block out and clear Uptodate on the page, and then we start spewing these errors.

Normally we're protected by the tree lock to a certain degree here. If we read a block we have that block read locked, and we block the writer from locking the block before we submit it for the write. However this isn't necessarily fool proof because the read could happen before we do the submit_bio and after we locked and unlocked the extent buffer.

Also in this particular case we have path->skip_locking set, so that won't save us here. We'll simply get a block that was valid when we read it, but became invalid while we were using it.

What we really want is to catch the case where we've "read" a block but it's not marked Uptodate. On read we ClearPageError(), so if we're !Uptodate and !Error we know we didn't do the right thing for reading the page.

Fix this by checking !Uptodate && !Error, this way we will not complain if our buffer gets invalidated while we're using it, and we'll maintain the spirit of the check which is to make sure we have a fully in-cache block while we're messing with it.(CVE-2022-48902)

ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.(CVE-2023-45896)

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

powerpc/pseries/memhp: Fix access beyond end of drmem array

dlparmemoryremovebyindex() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmeminfo->lmbs[drmeminfo->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer:

    pr_debug("Failed to hot-remove memory at %llx\n",
             lmb->base_addr);

This was found by inspection and confirmed with KASAN:

pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949

dumpstacklvl+0xa4/0xfc (unreliable) printreport+0x214/0x63c kasanreport+0x140/0x2e0 _asanload8+0xa8/0xe0 dlparmemory+0x298/0x1658 handledlparerrorlog+0x130/0x1d0 dlparstore+0x18c/0x3e0 kobjattrstore+0x68/0xa0 sysfskfwrite+0xc4/0x110 kernfsfopwriteiter+0x26c/0x390 vfswrite+0x2d4/0x4e0 ksyswrite+0xac/0x1a0 systemcallexception+0x268/0x530 systemcallvectoredcommon+0x15c/0x2ec

Allocated by task 1: kasansavestack+0x48/0x80 kasansettrack+0x34/0x50 kasansaveallocinfo+0x34/0x50 _kasankmalloc+0xd0/0x120 _kmalloc+0x8c/0x320 kmallocarray.constprop.0+0x48/0x5c drmeminit+0x2a0/0x41c dooneinitcall+0xe0/0x5c0 kernelinitfreeable+0x4ec/0x5a0 kernelinit+0x30/0x1e0 retfromkerneluser_thread+0x14/0x1c

The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0)

================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0

Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry.(CVE-2023-52451)

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

serial: sc16is7xx: convert from raw to noinc regmap functions for FIFO

The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte.

The regmaprawread() and regmaprawwrite() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly.

Convert FIFO R/W functions to use the regmap noinc versions in order to remove the manual cache control which was a workaround when using the raw versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses.(CVE-2023-52488)

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

media: imon: fix access to invalid resource for the second interface

imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.

This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.(CVE-2023-52754)

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

usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency

In dwc2hcdurbenqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In dwc2hcdurbdequeue():

spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
    dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
    goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...

out: spinunlockirqrestore(&hsotg->lock, flags);

When dwc2hcdurbenqueue() and dwc2hcdurbdequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2hcdurb_dequeue(), which can cause a NULL pointer dereference.

This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5.

To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic.(CVE-2023-52855)

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

bna: ensure the copied buf is NUL terminated

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

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

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

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

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

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:

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

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

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

dma: fix call order in dmamfreecoherent

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

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

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

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

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

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

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

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

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

The following calltrace will be seen:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

fuse: Initialize beyond-EOF page contents before setting uptodate

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

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

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

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

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

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

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

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

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

mptcp: pm: avoid possible UaF when selecting endp

selectlocaladdress() and selectsignaladdress() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free.

A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.(CVE-2024-44974)