CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2022-49879 – ext4: fix BUG_ON() when directory entry has invalid rec_len
https://notcve.org/view.php?id=CVE-2022-49879
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: fix BUG_ON() when directory entry has invalid rec_len The rec_len field in the directory entry has to be a multiple of 4. A corrupted filesystem image can be used to hit a BUG() in ext4_rec_len_to_disk(), called from make_indexed_dir(). ------------[ cut here ]------------ kernel BUG at fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Call Trace: <TASK> ? • https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-49878 – bpf, verifier: Fix memory leak in array reallocation for stack state
https://notcve.org/view.php?id=CVE-2022-49878
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf, verifier: Fix memory leak in array reallocation for stack state If an error (NULL) is returned by krealloc(), callers of realloc_array() were setting their allocation pointers to NULL, but on error krealloc() does not touch the original allocation. This would result in a memory resource leak. Instead, free the old allocation on the error handling path. The memory leak information is as follows as also reported by Zhengchao: unreference... • https://git.kernel.org/stable/c/c69431aab67a912836e5831f03d99a819c14c9c3 •
CVSS: 6.6EPSS: 0%CPEs: 7EXPL: 0CVE-2022-49877 – bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues
https://notcve.org/view.php?id=CVE-2022-49877
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues When running `test_sockmap` selftests, the following warning appears: WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Call Trace:
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-49876 – wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit()
https://notcve.org/view.php?id=CVE-2022-49876
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit() When device is running and the interface status is changed, the gpf issue is triggered. The problem triggering process is as follows: Thread A: Thread B ieee80211_runtime_change_iftype() process_one_work() ... ... ieee80211_do_stop() ... ... ... sdata->bss = NULL ... ... ieee80211_subif_start_xmit() ieee80211_multicast_to_unicast //!sdata->bss->multicast_to_unicast... • https://git.kernel.org/stable/c/f856373e2f31ffd340e47e2b00027bd4070f74b3 •
CVSS: 5.0EPSS: 0%CPEs: 4EXPL: 0CVE-2022-49875 – bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE
https://notcve.org/view.php?id=CVE-2022-49875
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE When using bpftool to pin {PROG, MAP, LINK} without FILE, segmentation fault will occur. The reson is that the lack of FILE will cause strlen to trigger NULL pointer dereference. The corresponding stacktrace is shown below: do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereference Fix it by adding validation to the common process. In... • https://git.kernel.org/stable/c/75a1e792c335b5c6d7fdb1014da47aeb64c5944f •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49874 – HID: hyperv: fix possible memory leak in mousevsc_probe()
https://notcve.org/view.php?id=CVE-2022-49874
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device(). In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device... • https://git.kernel.org/stable/c/74c4fb058083b47571a4f76dcfce95085f2d8098 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-49873 – bpf: Fix wrong reg type conversion in release_reference()
https://notcve.org/view.php?id=CVE-2022-49873
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: Fix wrong reg type conversion in release_reference() Some helper functions will allocate memory. To avoid memory leaks, the verifier requires the eBPF program to release these memories by calling the corresponding helper functions. When a resource is released, all pointer registers corresponding to the resource should be invalidated. The verifier use release_references() to do this job, by apply __mark_reg_unknown() to each relevant re... • https://git.kernel.org/stable/c/fd978bf7fd312581a7ca454a991f0ffb34c4204b •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2022-49872 – net: gso: fix panic on frag_list with mixed head alloc types
https://notcve.org/view.php?id=CVE-2022-49872
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list"), it is allowed to change gso_size of a GRO packet. However, that commit assumes that "checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too". It turns out this assumption do... • https://git.kernel.org/stable/c/162a5a8c3aff15c449e6b38355cdf80ab4f77a5a •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-49871 – net: tun: Fix memory leaks of napi_get_frags
https://notcve.org/view.php?id=CVE-2022-49871
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix memory leaks of napi_get_frags kmemleak reports after running test_progs: unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] ... • https://git.kernel.org/stable/c/90e33d45940793def6f773b2d528e9f3c84ffdc7 •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49870 – capabilities: fix undefined behavior in bit shift for CAP_TO_MASK
https://notcve.org/view.php?id=CVE-2022-49870
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: capabilities: fix undefined behavior in bit shift for CAP_TO_MASK Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in security/commoncap.c:1252:2 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: