CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44954 – ALSA: line6: Fix racy access to midibuf
https://notcve.org/view.php?id=CVE-2024-44954
In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races. • https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81 https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5 https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29 https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747 https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44949 – parisc: fix a possible DMA corruption
https://notcve.org/view.php?id=CVE-2024-44949
In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size. • https://git.kernel.org/stable/c/642a0b7453daff0295310774016fcb56d1f5bc7f https://git.kernel.org/stable/c/533de2f470baac40d3bf622fe631f15231a03c9f https://git.kernel.org/stable/c/7ae04ba36b381bffe2471eff3a93edced843240f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-44948 – x86/mtrr: Check if fixed MTRRs exist before saving them
https://notcve.org/view.php?id=CVE-2024-44948
In the Linux kernel, the following vulnerability has been resolved: x86/mtrr: Check if fixed MTRRs exist before saving them MTRRs have an obsolete fixed variant for fine grained caching control of the 640K-1MB region that uses separate MSRs. This fixed variant has a separate capability bit in the MTRR capability MSR. So far all x86 CPUs which support MTRR have this separate bit set, so it went unnoticed that mtrr_save_state() does not check the capability bit before accessing the fixed MTRR MSRs. Though on a CPU that does not support the fixed MTRR capability this results in a #GP. The #GP itself is harmless because the RDMSR fault is handled gracefully, but results in a WARN_ON(). Add the missing capability check to prevent this. • https://git.kernel.org/stable/c/2b1f6278d77c1f2f669346fc2bb48012b5e9495a https://git.kernel.org/stable/c/34f36e6ee5bd7eff8b2adcd9fcaef369f752d82e https://git.kernel.org/stable/c/06c1de44d378ec5439db17bf476507d68589bfe9 https://git.kernel.org/stable/c/450b6b22acdaac67a18eaf5ed498421ffcf10051 https://git.kernel.org/stable/c/ca7d00c5656d1791e28369919e3e10febe9c3b16 https://git.kernel.org/stable/c/8aa79dfb216b865e96ff890bc4ea71650f9bc8d7 https://git.kernel.org/stable/c/8a90d3fc7c24608548d3a750671f9dac21d1a462 https://git.kernel.org/stable/c/388f1c954019f253a8383f7eb733f38d5 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 1CVE-2024-44947 – fuse: Initialize beyond-EOF page contents before setting uptodate
https://notcve.org/view.php?id=CVE-2024-44947
In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() 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 CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter). • https://github.com/Abdurahmon3236/CVE-2024-44947 https://git.kernel.org/stable/c/a1d75f258230b75d46aecdf28b2e732413028863 https://git.kernel.org/stable/c/49934861514d36d0995be8e81bb3312a499d8d9a https://git.kernel.org/stable/c/33168db352c7b56ae18aa55c2cae1a1c5905d30e https://git.kernel.org/stable/c/4690e2171f651e2b415e3941ce17f2f7b813aff6 https://git.kernel.org/stable/c/8c78303eafbf85a728dd84d1750e89240c677dd9 https://git.kernel.org/stable/c/831433527773e665bdb635ab5783d0b95d1246f4 https://git.kernel.org/stable/c/ac42e0f0eb66af966015ee33fd355bc6f5d80cd6 https:&#x • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44942 – f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC
https://notcve.org/view.php?id=CVE-2024-44942
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback. Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing. • https://git.kernel.org/stable/c/ae00e6536a2dd54b64b39e9a39548870cf835745 https://git.kernel.org/stable/c/26c07775fb5dc74351d1c3a2bc3cdf609b03e49f https://git.kernel.org/stable/c/fc01008c92f40015aeeced94750855a7111b6929 •