Page 65 of 2833 results (0.017 seconds)

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To re... • https://git.kernel.org/stable/c/f6f50e28f0cb8d7bcdfaacc83129f005dede11b1 •

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unr... • https://git.kernel.org/stable/c/fa93854f7a7ed63d054405bf3779247d5300edd3 •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes th... • https://git.kernel.org/stable/c/9183c3f9ed710a8edf1a61e8a96d497258d26e08 •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if... • https://git.kernel.org/stable/c/b2f7b01d36a9b94fbd7489bd1228025ea7e7a2f4 •

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0... • https://git.kernel.org/stable/c/d877f07112f1e5a247c6b585c971a93895c9f738 •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_rem... • https://git.kernel.org/stable/c/7cf5c2978f23fdbb2dd7b4e8b07e362ae2d8211c •

CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_wo... • https://git.kernel.org/stable/c/7b064edae38d62d8587a8c574f93b53ce75ae749 •

CVSS: 7.5EPSS: 0%CPEs: 10EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following chara... • https://git.kernel.org/stable/c/960b360ca7463921c1a6b72e7066a706d6406223 • CWE-476: NULL Pointer Dereference •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this pa... • https://git.kernel.org/stable/c/1def9238d4aa2146924994aa4b7dc861f03b9362 •

CVSS: 5.7EPSS: 0%CPEs: 5EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len... • https://git.kernel.org/stable/c/342c88f406c2acd3dd00767aeacafe883cebb374 •