CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53099 – bpf: Check validity of link->type in bpf_link_show_fdinfo()
https://notcve.org/view.php?id=CVE-2024-53099
In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed. • https://git.kernel.org/stable/c/d5092b0a1aaf35d77ebd8d33384d7930bec5cb5d https://git.kernel.org/stable/c/b3eb1b6a9f745d6941b345f0fae014dc8bb06d36 https://git.kernel.org/stable/c/8421d4c8762bd022cb491f2f0f7019ef51b4f0a7 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53098 – drm/xe/ufence: Prefetch ufence addr to catch bogus address
https://notcve.org/view.php?id=CVE-2024-53098
In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/5d623ffbae96b23f1fc43a3d5a267aabdb07583d https://git.kernel.org/stable/c/9c1813b3253480b30604c680026c7dc721ce86d1 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-53097 – mm: krealloc: Fix MTE false alarm in __do_krealloc
https://notcve.org/view.php?id=CVE-2024-53097
In the Linux kernel, the following vulnerability has been resolved: mm: krealloc: Fix MTE false alarm in __do_krealloc This patch addresses an issue introduced by commit 1a83a716ec233 ("mm: krealloc: consider spare memory for __GFP_ZERO") which causes MTE (Memory Tagging Extension) to falsely report a slab-out-of-bounds error. The problem occurs when zeroing out spare memory in __do_krealloc. The original code only considered software-based KASAN and did not account for MTE. It does not reset the KASAN tag before calling memset, leading to a mismatch between the pointer tag and the memory tag, resulting in a false positive. Example of the error: ================================================================== swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188 swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1 swapper/0: Pointer tag: [f4], memory tag: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12. swapper/0: Hardware name: MT6991(ENG) (DT) swapper/0: Call trace: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c swapper/0: el1h_64_sync_handler+0x80/0xcc swapper/0: el1h_64_sync+0x68/0x6c swapper/0: __memset+0x84/0x188 swapper/0: btf_populate_kfunc_set+0x280/0x3d8 swapper/0: __register_btf_kfunc_id_set+0x43c/0x468 swapper/0: register_btf_kfunc_id_set+0x48/0x60 swapper/0: register_nf_nat_bpf+0x1c/0x40 swapper/0: nf_nat_init+0xc0/0x128 swapper/0: do_one_initcall+0x184/0x464 swapper/0: do_initcall_level+0xdc/0x1b0 swapper/0: do_initcalls+0x70/0xc0 swapper/0: do_basic_setup+0x1c/0x28 swapper/0: kernel_init_freeable+0x144/0x1b8 swapper/0: kernel_init+0x20/0x1a8 swapper/0: ret_from_fork+0x10/0x20 ================================================================== • https://git.kernel.org/stable/c/a543785856249a5ba8c20468098601c0c33b1224 https://git.kernel.org/stable/c/44f79667fefd52945a44d2a57a2cd3c554d7f4e0 https://git.kernel.org/stable/c/f8767d10bcbc2529540eb906906c0058e15cd918 https://git.kernel.org/stable/c/e3a9fc1520a6606c6121aca8d6679c6b93de7fd8 https://git.kernel.org/stable/c/3e9a65a38706866bf93e19f5b4936465188add10 https://git.kernel.org/stable/c/73388659ef0eea51747350530afdeadf8809ce9c https://git.kernel.org/stable/c/d02492863023431c31f85d570f718433c22b9311 https://git.kernel.org/stable/c/d43f1430d47c22a0727c05b6f156ed25f •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-53096 – mm: resolve faulty mmap_region() error path behaviour
https://notcve.org/view.php?id=CVE-2024-53096
In the Linux kernel, the following vulnerability has been resolved: mm: resolve faulty mmap_region() error path behaviour The mmap_region() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur. A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state. Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function __mmap_region(). Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE validation unconditionally also. We move a number of things here: 1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths. 2. The enclosing mmap_region() function handles the mapping_map_writable() logic early. Previously the logic had the mapping_map_writable() at the point of mapping a newly allocated file-backed VMA, and a matching mapping_unmap_writable() on success and error paths. We now do this unconditionally if this is a file-backed, shared writable mapping. • https://git.kernel.org/stable/c/a3c08c021778dad30f69895e378843e9f423d734 https://git.kernel.org/stable/c/43bed0a13a5cdbb314d14f28c2bf2c60eb4e6e1e https://git.kernel.org/stable/c/deb0f6562884b5b4beb883d73e66a7d3a1b96d99 https://git.kernel.org/stable/c/6757330b1be5b0606125b65ed50caac69bccf9a5 https://git.kernel.org/stable/c/66f2ed0172af04a89677ae1898600e1264e25800 https://git.kernel.org/stable/c/43323a4e5b3f8ccc08e2f835abfdc7ee9da8f6ed https://git.kernel.org/stable/c/44f48eb9a6051826227bbd375446064fb2a43c6c https://git.kernel.org/stable/c/52c81fd0f5a8bf8032687b94ccf00d13b •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53095 – smb: client: Fix use-after-free of network namespace.
https://notcve.org/view.php?id=CVE-2024-53095
In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler()."). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. • https://git.kernel.org/stable/c/26abe14379f8e2fa3fd1bcf97c9a7ad9364886fe https://git.kernel.org/stable/c/e8c71494181153a134c96da28766a57bd1eac8cb https://git.kernel.org/stable/c/c7f9282fc27fc36dbaffc8527c723de264a132f8 https://git.kernel.org/stable/c/ef7134c7fc48e1441b398e55a862232868a6f0a7 • CWE-416: Use After Free •