CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50215 – nvmet-auth: assign dh_key to NULL after kfree_sensitive
https://notcve.org/view.php?id=CVE-2024-50215
In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace. • https://git.kernel.org/stable/c/7a277c37d3522e9b2777d762bbbcecafae2b1f8d https://git.kernel.org/stable/c/c94e965f766321641ec38e4eece9ce8884543244 https://git.kernel.org/stable/c/c60af16e1d6cc2237d58336546d6adfc067b6b8f https://git.kernel.org/stable/c/e61bd51e44409495d75847e9230736593e4c8710 https://git.kernel.org/stable/c/d2f551b1f72b4c508ab9298419f6feadc3b5d791 •
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 •