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: -EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-4442 – tcp: add sanity tests to TCP_QUEUE_SEQ
https://notcve.org/view.php?id=CVE-2021-4442
In the Linux kernel, the following vulnerability has been resolved: tcp: add sanity tests to TCP_QUEUE_SEQ Qingyu Li reported a syzkaller bug where the repro changes RCV SEQ _after_ restoring data in the receive queue. mprotect(0x4aa000, 12288, PROT_READ) = 0 mmap(0x1ffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1ffff000 mmap(0x20000000, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000 mmap(0x21000000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x21000000 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3 setsockopt(3, SOL_TCP, TCP_REPAIR, [1], 4) = 0 connect(3, {sa_family=AF_INET6, sin6_port=htons(0), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0 setsockopt(3, SOL_TCP, TCP_REPAIR_QUEUE, [1], 4) = 0 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="0x0000000000000003\0\0", iov_len=20}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20 setsockopt(3, SOL_TCP, TCP_REPAIR, [0], 4) = 0 setsockopt(3, SOL_TCP, TCP_QUEUE_SEQ, [128], 4) = 0 recvfrom(3, NULL, 20, 0, NULL, NULL) = -1 ECONNRESET (Connection reset by peer) syslog shows: [ 111.205099] TCP recvmsg seq # bug 2: copied 80, seq 0, rcvnxt 80, fl 0 [ 111.207894] WARNING: CPU: 1 PID: 356 at net/ipv4/tcp.c:2343 tcp_recvmsg_locked+0x90e/0x29a0 This should not be allowed. TCP_QUEUE_SEQ should only be used when queues are empty. This patch fixes this case, and the tx path as well. • https://git.kernel.org/stable/c/ee9952831cfd0bbe834f4a26489d7dce74582e37 https://git.kernel.org/stable/c/319f460237fc2965a80aa9a055044e1da7b3692a https://git.kernel.org/stable/c/3bf899438c123c444f6b644a57784dfbb6b15ad6 https://git.kernel.org/stable/c/046f3c1c2ff450fb7ae53650e9a95e0074a61f3e https://git.kernel.org/stable/c/3b72d5a703842f582502d97906f17d6ee122dac2 https://git.kernel.org/stable/c/8811f4a9836e31c14ecdf79d9f3cb7c5d463265d •
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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44941 – f2fs: fix to cover read extent cache access with lock
https://notcve.org/view.php?id=CVE-2024-44941
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to cover read extent cache access with lock syzbot reports a f2fs bug as below: BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097 CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 do_read_inode fs/f2fs/inode.c:509 [inline] f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560 f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237 generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413 exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444 exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584 do_handle_to_path fs/fhandle.c:155 [inline] handle_to_path fs/fhandle.c:210 [inline] do_handle_open+0x495/0x650 fs/fhandle.c:226 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We missed to cover sanity_check_extent_cache() w/ extent cache lock, so, below race case may happen, result in use after free issue. - f2fs_iget - do_read_inode - f2fs_init_read_extent_tree : add largest extent entry in to cache - shrink - f2fs_shrink_read_extent_tree - __shrink_extent_tree - __detach_extent_node : drop largest extent entry - sanity_check_extent_cache : access et->largest w/o lock let's refactor sanity_check_extent_cache() to avoid extent cache access and call it before f2fs_init_read_extent_tree() to fix this issue. • https://git.kernel.org/stable/c/263df78166d3a9609b97d28c34029bd01874cbb8 https://git.kernel.org/stable/c/323ef20b5558b9d9fd10c1224327af6f11a8177d https://git.kernel.org/stable/c/d7409b05a64f212735f0d33f5f1602051a886eab •