CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-41000 – block/ioctl: prefer different overflow check
https://notcve.org/view.php?id=CVE-2024-41000
In the Linux kernel, the following vulnerability has been resolved: block/ioctl: prefer different overflow check Running syzkaller with the newly reintroduced signed integer overflow sanitizer shows this report: [ 62.982337] ------------[ cut here ]------------ [ 62.985692] cgroup: Invalid name [ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46 [ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1 [ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long' [ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1 [ 62.999369] random: crng reseeded on system resumption [ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000) [ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 63.000682] Call Trace: [ 63.000686] <TASK> [ 63.000731] dump_stack_lvl+0x93/0xd0 [ 63.000919] __get_user_pages+0x903/0xd30 [ 63.001030] __gup_longterm_locked+0x153e/0x1ba0 [ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50 [ 63.001072] ? try_get_folio+0x29c/0x2d0 [ 63.001083] internal_get_user_pages_fast+0x1119/0x1530 [ 63.001109] iov_iter_extract_pages+0x23b/0x580 [ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220 [ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410 [ 63.001297] __iomap_dio_rw+0xab4/0x1810 [ 63.001316] iomap_dio_rw+0x45/0xa0 [ 63.001328] ext4_file_write_iter+0xdde/0x1390 [ 63.001372] vfs_write+0x599/0xbd0 [ 63.001394] ksys_write+0xc8/0x190 [ 63.001403] do_syscall_64+0xd4/0x1b0 [ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60 [ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77 [ 63.001535] RIP: 0033:0x7f7fd3ebf539 [ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 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 [ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539 [ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004 [ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000 [ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8 ... [ 63.018142] ---[ end trace ]--- Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang; It was re-enabled in the kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow sanitizer"). Let's rework this overflow checking logic to not actually perform an overflow during the check itself, thus avoiding the UBSAN splat. [1]: https://github.com/llvm/llvm-project/pull/82432 • https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24 https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66 https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9 https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-40999 – net: ena: Add validation for completion descriptors consistency
https://notcve.org/view.php?id=CVE-2024-40999
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. • https://git.kernel.org/stable/c/42146ee5286f16f1674a84f7c274dcca65c6ff2e https://git.kernel.org/stable/c/b37b98a3a0c1198bafe8c2d9ce0bc845b4e7a9a7 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40998 – ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()
https://notcve.org/view.php?id=CVE-2024-40998
In the Linux kernel, the following vulnerability has been resolved: ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super() In the following concurrency we will access the uninitialized rs->lock: ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, _RET_IP_) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock here and get the following dump_stack: ========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4] [...] ========================================================= Normally interval is 0 until s_msg_ratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems. • https://git.kernel.org/stable/c/23afcd52af06880c6c913a0ad99022b8937b575c https://git.kernel.org/stable/c/645267906944a9aeec9d5c56ee24a9096a288798 https://git.kernel.org/stable/c/b4b4fda34e535756f9e774fb2d09c4537b7dfd1c https://access.redhat.com/security/cve/CVE-2024-40998 https://bugzilla.redhat.com/show_bug.cgi?id=2297582 •
CVSS: 5.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-40997 – cpufreq: amd-pstate: fix memory leak on CPU EPP exit
https://notcve.org/view.php?id=CVE-2024-40997
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: fix memory leak on CPU EPP exit The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that. [ rjw: Subject and changelog edits ] • https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582 https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81 https://access.redhat.com/security/cve/CVE-2024-40997 https://bugzilla.redhat.com/show_bug.cgi?id=2297581 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-40996 – bpf: Avoid splat in pskb_pull_reason
https://notcve.org/view.php?id=CVE-2024-40996
In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid splat in pskb_pull_reason syzkaller builds (CONFIG_DEBUG_NET=y) frequently trigger a debug hint in pskb_may_pull. We'd like to retain this debug check because it might hint at integer overflows and other issues (kernel code should pull headers, not huge value). In bpf case, this splat isn't interesting at all: such (nonsensical) bpf programs are typically generated by a fuzzer anyway. Do what Eric suggested and suppress such warning. For CONFIG_DEBUG_NET=n we don't need the extra check because pskb_may_pull will do the right thing: return an error without the WARN() backtrace. • https://git.kernel.org/stable/c/8af60bb2b215f478b886f1d6d302fefa7f0b917d https://git.kernel.org/stable/c/1b2b26595bb09febf14c5444c873ac4ec90a5a77 https://git.kernel.org/stable/c/219eee9c0d16f1b754a8b85275854ab17df0850a https://git.kernel.org/stable/c/fff05b2b004d9a8a2416d08647f3dc9068e357c8 https://git.kernel.org/stable/c/dacc15e9cb248d19e5fc63c54bef0b9b55007761 https://git.kernel.org/stable/c/7f9644782c559635bd676c12c59389a34ed7c866 https://git.kernel.org/stable/c/5e90258303a358e88737afb5048bee9113beea3a https://git.kernel.org/stable/c/2bbe3e5a2f4ef69d13be54f1cf895b465 •