Page 61 of 2542 results (0.026 seconds)

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

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 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix UBSAN warning in kv_dpm.c Adds bounds check for sumo_vid_mapping_entry. • https://git.kernel.org/stable/c/07e8f15fa16695cf4c90e89854e59af4a760055b https://git.kernel.org/stable/c/a8c6df9fe5bc390645d1e96eff14ffe414951aad https://git.kernel.org/stable/c/febe794b83693257f21a23d2e03ea695a62449c8 https://git.kernel.org/stable/c/cf1cc8fcfe517e108794fb711f7faabfca0dc855 https://git.kernel.org/stable/c/f803532bc3825384100dfc58873e035d77248447 https://git.kernel.org/stable/c/9e57611182a817824a17b1c3dd300ee74a174b42 https://git.kernel.org/stable/c/468a50fd46a09bba7ba18a11054ae64b6479ecdc https://git.kernel.org/stable/c/a498df5421fd737d11bfd152428ba6b1c •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix UBSAN warning in kv_dpm.c Adds bounds check for sumo_vid_mapping_entry. • https://git.kernel.org/stable/c/4ad7d49059358ceadd352b4e2511425bdb68f400 https://git.kernel.org/stable/c/1c44f7759a5650acf8f13d3e0a184d09e03be9e4 https://git.kernel.org/stable/c/d8a04a6bfa75251ba7bcc3651ed211e82f13f388 https://git.kernel.org/stable/c/4d020c1dbd2b2304f44d003e6de956ae570049dc https://git.kernel.org/stable/c/fc5cb952e6723c5c55e47b8cf94a891bd4af1a86 https://git.kernel.org/stable/c/b065d79ed06a0bb4377bc6dcc2ff0cb1f55a798f https://git.kernel.org/stable/c/b0d612619ed70cab476c77b19e00d13aa414e14f https://git.kernel.org/stable/c/f0d576f840153392d04b2d52cf3adab8f •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine." Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. • https://git.kernel.org/stable/c/d410ee5109a1633a686a5663c6743a92e1181f9b https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98 https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239 https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3 https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b4 • CWE-476: NULL Pointer Dereference •