Page 38 of 3965 results (0.033 seconds)

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

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 resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code. • https://git.kernel.org/stable/c/f6f50e28f0cb8d7bcdfaacc83129f005dede11b1 https://git.kernel.org/stable/c/bf605ae98dab5c15c5b631d4d7f88898cb41b649 https://git.kernel.org/stable/c/ff55291fb36779819211b596da703389135f5b05 https://git.kernel.org/stable/c/82dfdd1e31e774578f76ce6dc90c834f96403a0f https://git.kernel.org/stable/c/86a89e75e9e4dfa768b97db466ad6bedf2e7ea5b https://git.kernel.org/stable/c/f60e94a83db799bde625ac8671a5b4a6354e7120 https://git.kernel.org/stable/c/387bf565cc03e2e8c720b8b4798efea4aacb6962 https://git.kernel.org/stable/c/5784d9fcfd43bd853654bb80c87ef293b •

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

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 unregistered so that they can be ignored by battery_hook_unregister(). • https://git.kernel.org/stable/c/fa93854f7a7ed63d054405bf3779247d5300edd3 https://git.kernel.org/stable/c/da964de4c18199e14b961b5b2e5e6570552a313c https://git.kernel.org/stable/c/07b98400cb0285a6348188aa8c5ec6a2ae0551f7 https://git.kernel.org/stable/c/ca1fb7942a287b40659cc79551a1de54a2c2e7d5 https://git.kernel.org/stable/c/ce31847f109c3a5b2abdd19d7bcaafaacfde53de https://git.kernel.org/stable/c/ca26e8eed9c1c6651f51f7fa38fe444f8573cd1b https://git.kernel.org/stable/c/9f469ef1c79dac7f9ac1518643a33703918f7e13 https://git.kernel.org/stable/c/76959aff14a0012ad6b984ec7686d163d •

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

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 the machine out when panic_on_warn is set. Replace it with a pr_warn(). • https://git.kernel.org/stable/c/9183c3f9ed710a8edf1a61e8a96d497258d26e08 https://git.kernel.org/stable/c/bc9356513d56b688775497b7ac6f2b967f46a80c https://git.kernel.org/stable/c/ea2cdf4da093d0482f0ef36ba971e2e0c7673425 https://git.kernel.org/stable/c/e67534bd31d79952b50e791e92adf0b3e6c13b8c https://git.kernel.org/stable/c/85a104aaef1f56623acc10ba4c42d5f046ba65b7 https://git.kernel.org/stable/c/b83bef74c121a3311240fc4002d23486b85355e4 https://git.kernel.org/stable/c/fe513c2ef0a172a58f158e2e70465c4317f0a9a2 •

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

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 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK> • https://git.kernel.org/stable/c/d877f07112f1e5a247c6b585c971a93895c9f738 https://git.kernel.org/stable/c/531754952f5dfc4b141523088147071d6e6112c4 https://git.kernel.org/stable/c/38e3fd0c4a2616052eb3c8f4e6f32d1ff47cd663 https://git.kernel.org/stable/c/b40b027a0c0cc1cb9471a13f9730bb2fff12a15b https://git.kernel.org/stable/c/4e3542f40f3a94efa59ea328e307c50601ed7065 https://git.kernel.org/stable/c/f839c5cd348201fec440d987cbca9b979bdb4fa7 https://git.kernel.org/stable/c/752e1924604254f1708f3e3700283a86ebdd325d https://git.kernel.org/stable/c/92ceba94de6fb4cee2bf40b485979c342 •

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

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_removed this attempts to dequeue commands passed as user_data to cmd_sync. • https://git.kernel.org/stable/c/7cf5c2978f23fdbb2dd7b4e8b07e362ae2d8211c https://git.kernel.org/stable/c/4883296505aa7e4863c6869b689afb6005633b23 https://git.kernel.org/stable/c/0cc47233af35fb5f10b5e6a027cb4ccd480caf9a https://git.kernel.org/stable/c/8c3f7943a29145d8a2d8e24893762f7673323eae https://git.kernel.org/stable/c/f53e1c9c726d83092167f2226f32bd3b73f26c21 •