CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43912 – wifi: nl80211: disallow setting special AP channel widths
https://notcve.org/view.php?id=CVE-2024-43912
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: disallow setting special AP channel widths Setting the AP channel width is meant for use with the normal 20/40/... MHz channel width progression, and switching around in S1G or narrow channels isn't supported. Disallow that. • https://git.kernel.org/stable/c/3d42f2125f6c89e1e71c87b9f23412afddbba45e https://git.kernel.org/stable/c/c6ea738e3feb407a3283197d9a25d0788f4f3cee https://git.kernel.org/stable/c/ac3bf6e47fd8da9bfe8027e1acfe0282a91584fc https://git.kernel.org/stable/c/23daf1b4c91db9b26f8425cc7039cf96d22ccbfe •
CVSS: 5.7EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43911 – wifi: mac80211: fix NULL dereference at band check in starting tx ba session
https://notcve.org/view.php?id=CVE-2024-43911
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL dereference at band check in starting tx ba session In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink. Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Code starting with the faulting instruction =========================================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? • https://git.kernel.org/stable/c/0acaf4a5025d6dafb7da787d2d4c47ed95e46ed6 https://git.kernel.org/stable/c/a53c2d847627b790fb3bd8b00e02c247941b17e0 https://git.kernel.org/stable/c/a5594c1e03b0df3908b1e1202a1ba34422eed0f6 https://git.kernel.org/stable/c/021d53a3d87eeb9dbba524ac515651242a2a7e3b https://access.redhat.com/security/cve/CVE-2024-43911 https://bugzilla.redhat.com/show_bug.cgi?id=2307884 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43910 – bpf: add missing check_func_arg_reg_off() to prevent out-of-bounds memory accesses
https://notcve.org/view.php?id=CVE-2024-43910
In the Linux kernel, the following vulnerability has been resolved: bpf: add missing check_func_arg_reg_off() to prevent out-of-bounds memory accesses Currently, it's possible to pass in a modified CONST_PTR_TO_DYNPTR to a global function as an argument. The adverse effects of this is that BPF helpers can continue to make use of this modified CONST_PTR_TO_DYNPTR from within the context of the global function, which can unintentionally result in out-of-bounds memory accesses and therefore compromise overall system stability i.e. [ 244.157771] BUG: KASAN: slab-out-of-bounds in bpf_dynptr_data+0x137/0x140 [ 244.161345] Read of size 8 at addr ffff88810914be68 by task test_progs/302 [ 244.167151] CPU: 0 PID: 302 Comm: test_progs Tainted: G O E 6.10.0-rc3-00131-g66b586715063 #533 [ 244.174318] Call Trace: [ 244.175787] <TASK> [ 244.177356] dump_stack_lvl+0x66/0xa0 [ 244.179531] print_report+0xce/0x670 [ 244.182314] ? __virt_addr_valid+0x200/0x3e0 [ 244.184908] kasan_report+0xd7/0x110 [ 244.187408] ? bpf_dynptr_data+0x137/0x140 [ 244.189714] ? bpf_dynptr_data+0x137/0x140 [ 244.192020] bpf_dynptr_data+0x137/0x140 [ 244.194264] bpf_prog_b02a02fdd2bdc5fa_global_call_bpf_dynptr_data+0x22/0x26 [ 244.198044] bpf_prog_b0fe7b9d7dc3abde_callback_adjust_bpf_dynptr_reg_off+0x1f/0x23 [ 244.202136] bpf_user_ringbuf_drain+0x2c7/0x570 [ 244.204744] ? • https://git.kernel.org/stable/c/a64bfe618665ea9c722f922cba8c6e3234eac5ac https://git.kernel.org/stable/c/13663a7c644bf1dedaf461d07252db5d76c8759a https://git.kernel.org/stable/c/ec2b9a5e11e51fea1bb04c1e7e471952e887e874 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43909 – drm/amdgpu/pm: Fix the null pointer dereference for smu7
https://notcve.org/view.php?id=CVE-2024-43909
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix the null pointer dereference for smu7 optimize the code to avoid pass a null pointer (hwmgr->backend) to function smu7_update_edc_leakage_table. • https://git.kernel.org/stable/c/37b9df457cbcf095963d18f17d6cb7dfa0a03fce https://git.kernel.org/stable/c/1b8aa82b80bd947b68a8ab051d960a0c7935e22d https://git.kernel.org/stable/c/09544cd95c688d3041328a4253bd7514972399bb https://git.kernel.org/stable/c/7f56f050f02c27ed89cce1ea0c04b34abce32751 https://git.kernel.org/stable/c/c02c1960c93eede587576625a1221205a68a904f •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43908 – drm/amdgpu: Fix the null pointer dereference to ras_manager
https://notcve.org/view.php?id=CVE-2024-43908
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the null pointer dereference to ras_manager Check ras_manager before using it • https://git.kernel.org/stable/c/ff5c4eb71ee8951c789b079f6e948f86708b04ed https://git.kernel.org/stable/c/d81c1eeb333d84b3012a91c0500189dc1d71e46c https://git.kernel.org/stable/c/56e848034ccabe44e8f22ffcf49db771c17b0d0a https://git.kernel.org/stable/c/48cada0ac79e4775236d642e9ec5998a7c7fb7a4 https://git.kernel.org/stable/c/b89616333979114bb0da5fa40fb6e4a2f5294ca2 https://git.kernel.org/stable/c/033187a70ba9743c73a810a006816e5553d1e7d4 https://git.kernel.org/stable/c/4c11d30c95576937c6c35e6f29884761f2dddb43 •