CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50213 – drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()
https://notcve.org/view.php?id=CVE-2024-50213
In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: unreferenced object 0xffffff80ccd18100 (size 128): comm "kunit_try_catch", pid 1851, jiffies 4295059695 hex dump (first 32 bytes): 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ backtrace (crc c2f1aa95): [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 [<0000000019daaacf>] 0xffffffedc11ae69c [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec [<000000000a0b2e9e>] kthread+0x2e8/0x374 [<00000000bd668858>] ret_from_fork+0x10/0x20 ...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it. • https://git.kernel.org/stable/c/4af70f19e55904147c0515ff874204a5306ac807 https://git.kernel.org/stable/c/3bc3fae8a0f22e0e713729b50e2111f6a8c64724 https://git.kernel.org/stable/c/add4163aca0d4a86e9fe4aa513865e4237db8aef •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50212 – lib: alloc_tag_module_unload must wait for pending kfree_rcu calls
https://notcve.org/view.php?id=CVE-2024-50212
In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment] • https://git.kernel.org/stable/c/a473573964e51dcb6efc182f773cd3924be4a184 https://git.kernel.org/stable/c/24211fb49c9ac1b576470b7e393a5a0b50af2707 https://git.kernel.org/stable/c/dc783ba4b9df3fb3e76e968b2cbeb9960069263c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50211 – udf: refactor inode_bmap() to handle error
https://notcve.org/view.php?id=CVE-2024-50211
In the Linux kernel, the following vulnerability has been resolved: udf: refactor inode_bmap() to handle error Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions. • https://git.kernel.org/stable/c/493447dd8336607fce426f7879e581095f6c606e https://git.kernel.org/stable/c/b22d9a5698abf04341f8fbc30141e0673863c3a6 https://git.kernel.org/stable/c/c226964ec786f3797ed389a16392ce4357697d24 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50210 – posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()
https://notcve.org/view.php?id=CVE-2024-50210
In the Linux kernel, the following vulnerability has been resolved: posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that. [pabeni@redhat.com: fixed commit message typo] • https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073 https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01 https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2 https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264 https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943 https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593aa0449af https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a415 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50209 – RDMA/bnxt_re: Add a check for memory allocation
https://notcve.org/view.php?id=CVE-2024-50209
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances. • https://git.kernel.org/stable/c/0c4dcd602817502bb3dced7a834a13ef717d65a4 https://git.kernel.org/stable/c/dbe51dd516e6d4e655f31c8a1cbc050dde7ba97b https://git.kernel.org/stable/c/322a19baaaa25a1fe8ce9fceaed9409ad847844c https://git.kernel.org/stable/c/76dd679c3b148d23f72dcf6c3cde3d5f746b2c07 https://git.kernel.org/stable/c/c71957271f2e8133a6aa82001c2fa671d5008129 https://git.kernel.org/stable/c/ba9045887b435a4c5551245ae034b8791b4e4aaa https://git.kernel.org/stable/c/c5c1ae73b7741fa3b58e6e001b407825bb971225 •