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: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-40995 – net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
https://notcve.org/view.php?id=CVE-2024-40995
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() syzbot found hanging tasks waiting on rtnl_lock [1] A reproducer is available in the syzbot bug. When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang. Return -EAGAIN to prevent infinite looping, while keeping documented behavior. [1] INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: events_power_efficient reg_check_chans_work Call Trace: <TASK> context_switch kernel/sched/core.c:5409 [inline] __schedule+0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [inline] reg_leave_invalid_chans net/wireless/reg.c:2466 [inline] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481 • https://git.kernel.org/stable/c/0190c1d452a91c38a3462abdd81752be1b9006a8 https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74 https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90 https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4 https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2 https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335 https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-40990 – RDMA/mlx5: Add check for srq max_sge attribute
https://notcve.org/view.php?id=CVE-2024-40990
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Add check for srq max_sge attribute max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it. • https://git.kernel.org/stable/c/e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c https://git.kernel.org/stable/c/7186b81c1f15e39069b1af172c6a951728ed3511 https://git.kernel.org/stable/c/1e692244bf7dd827dd72edc6c4a3b36ae572f03c https://git.kernel.org/stable/c/999586418600b4b3b93c2a0edd3a4ca71ee759bf https://git.kernel.org/stable/c/e0deb0e9c967b61420235f7f17a4450b4b4d6ce2 https://git.kernel.org/stable/c/4ab99e3613139f026d2d8ba954819e2876120ab3 https://git.kernel.org/stable/c/36ab7ada64caf08f10ee5a114d39964d1f91e81d •