CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50254 – bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()
https://notcve.org/view.php?id=CVE-2024-50254
In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses "kit->nr_bits <= 64" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm "swapper/0", pid 1, jiffies 4294727320 hex dump (first 32 bytes): b0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... f0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): [<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 [<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 [<00000000597124d6>] __alloc.isra.0+0x89/0xb0 [<000000004ebfffcd>] alloc_bulk+0x2af/0x720 [<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 [<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 [<000000008b616eac>] bpf_global_ma_init+0x19/0x30 [<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 [<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 [<00000000b119f72f>] kernel_init+0x20/0x160 [<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 [<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use "!nr_bits || bits >= nr_bits" to check whether the iteration is complete and still use "nr_bits > 64" to indicate whether bits are dynamically allocated. The "! • https://git.kernel.org/stable/c/4665415975b0827e9646cab91c61d02a6b364d59 https://git.kernel.org/stable/c/9cee266fafaf79fd465314546f637f9a3c215830 https://git.kernel.org/stable/c/101ccfbabf4738041273ce64e2b116cf440dea13 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50253 – bpf: Check the validity of nr_words in bpf_iter_bits_new()
https://notcve.org/view.php?id=CVE-2024-50253
In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes. • https://git.kernel.org/stable/c/4665415975b0827e9646cab91c61d02a6b364d59 https://git.kernel.org/stable/c/c9539e09c67880ecd88b51188c346a2cc078b06c https://git.kernel.org/stable/c/393397fbdcad7396639d7077c33f86169184ba99 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50252 – mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address
https://notcve.org/view.php?id=CVE-2024-50252
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: <TASK> mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm "ip", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0 • https://git.kernel.org/stable/c/cf42911523e02026cb56d329e584ae5923e94ba1 https://git.kernel.org/stable/c/d8f298eb6659eb6a38e26b79e77de4449dc6e61b https://git.kernel.org/stable/c/31384aa2ad05c29c7745000f321154f42de24d1a https://git.kernel.org/stable/c/c1bbdbe07f0bc3bc9f87efe4672d67208c6d6942 https://git.kernel.org/stable/c/12ae97c531fcd3bfd774d4dfeaeac23eafe24280 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50251 – netfilter: nft_payload: sanitize offset and length before calling skb_checksum()
https://notcve.org/view.php?id=CVE-2024-50251
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed. • https://git.kernel.org/stable/c/7ec3f7b47b8d9ad7ba425726f2c58f9ddce040df https://git.kernel.org/stable/c/a661ed364ae6ae88c2fafa9ddc27df1af2a73701 https://git.kernel.org/stable/c/ac7df3fc80fc82bcc3b1e8f6ebc0d2c435d0c534 https://git.kernel.org/stable/c/e3e608cbad376674d19a71ccd0d41804d9393f02 https://git.kernel.org/stable/c/b1d2de8a669fa14c499a385e056944d5352b3b40 https://git.kernel.org/stable/c/d3217323525f7596427124359e76ea0d8fcc9874 https://git.kernel.org/stable/c/0ab3be58b45b996764aba0187b46de19b3e58a72 https://git.kernel.org/stable/c/c43e0ea848e7b9bef7a682cbc5608022d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50250 – fsdax: dax_unshare_iter needs to copy entire blocks
https://notcve.org/view.php?id=CVE-2024-50250
In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on. • https://git.kernel.org/stable/c/1bec6782a25c9b92c203ea7a1b3e3dc6a468cbc4 https://git.kernel.org/stable/c/d984648e428bf88cbd94ebe346c73632cb92fffb https://git.kernel.org/stable/c/bdbc96c23197d773a7d1bf03e4f11de593b0ff28 https://git.kernel.org/stable/c/9bc18bb476e50e32e5d08f2734d63d63e0fa528c https://git.kernel.org/stable/c/8e9c0f500b42216ef930f5c0d1703989a451913d https://git.kernel.org/stable/c/50793801fc7f6d08def48754fb0f0706b0cfc394 •