Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Fix shift-out-of-bounds in dbDiscardAG<br /> <br /> When searching for the next smaller log2 block, BLKSTOL2() returned 0,<br /> causing shift exponent -1 to be negative.<br /> <br /> This patch fixes the issue by exiting the loop directly when negative<br /> shift is found.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: add missing check_func_arg_reg_off() to prevent out-of-bounds memory accesses<br /> <br /> Currently, it&amp;#39;s possible to pass in a modified CONST_PTR_TO_DYNPTR to<br /> a global function as an argument. The adverse effects of this is that<br /> BPF helpers can continue to make use of this modified<br /> CONST_PTR_TO_DYNPTR from within the context of the global function,<br /> which can unintentionally result in out-of-bounds memory accesses and<br /> therefore compromise overall system stability i.e.<br /> <br /> [ 244.157771] BUG: KASAN: slab-out-of-bounds in bpf_dynptr_data+0x137/0x140<br /> [ 244.161345] Read of size 8 at addr ffff88810914be68 by task test_progs/302<br /> [ 244.167151] CPU: 0 PID: 302 Comm: test_progs Tainted: G O E 6.10.0-rc3-00131-g66b586715063 #533<br /> [ 244.174318] Call Trace:<br /> [ 244.175787] <br /> [ 244.177356] dump_stack_lvl+0x66/0xa0<br /> [ 244.179531] print_report+0xce/0x670<br /> [ 244.182314] ? __virt_addr_valid+0x200/0x3e0<br /> [ 244.184908] kasan_report+0xd7/0x110<br /> [ 244.187408] ? bpf_dynptr_data+0x137/0x140<br /> [ 244.189714] ? bpf_dynptr_data+0x137/0x140<br /> [ 244.192020] bpf_dynptr_data+0x137/0x140<br /> [ 244.194264] bpf_prog_b02a02fdd2bdc5fa_global_call_bpf_dynptr_data+0x22/0x26<br /> [ 244.198044] bpf_prog_b0fe7b9d7dc3abde_callback_adjust_bpf_dynptr_reg_off+0x1f/0x23<br /> [ 244.202136] bpf_user_ringbuf_drain+0x2c7/0x570<br /> [ 244.204744] ? 0xffffffffc0009e58<br /> [ 244.206593] ? __pfx_bpf_user_ringbuf_drain+0x10/0x10<br /> [ 244.209795] bpf_prog_33ab33f6a804ba2d_user_ringbuf_callback_const_ptr_to_dynptr_reg_off+0x47/0x4b<br /> [ 244.215922] bpf_trampoline_6442502480+0x43/0xe3<br /> [ 244.218691] __x64_sys_prlimit64+0x9/0xf0<br /> [ 244.220912] do_syscall_64+0xc1/0x1d0<br /> [ 244.223043] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 244.226458] RIP: 0033:0x7ffa3eb8f059<br /> [ 244.228582] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8f 1d 0d 00 f7 d8 64 89 01 48<br /> [ 244.241307] RSP: 002b:00007ffa3e9c6eb8 EFLAGS: 00000206 ORIG_RAX: 000000000000012e<br /> [ 244.246474] RAX: ffffffffffffffda RBX: 00007ffa3e9c7cdc RCX: 00007ffa3eb8f059<br /> [ 244.250478] RDX: 00007ffa3eb162b4 RSI: 0000000000000000 RDI: 00007ffa3e9c7fb0<br /> [ 244.255396] RBP: 00007ffa3e9c6ed0 R08: 00007ffa3e9c76c0 R09: 0000000000000000<br /> [ 244.260195] R10: 0000000000000000 R11: 0000000000000206 R12: ffffffffffffff80<br /> [ 244.264201] R13: 000000000000001c R14: 00007ffc5d6b4260 R15: 00007ffa3e1c7000<br /> [ 244.268303] <br /> <br /> Add a check_func_arg_reg_off() to the path in which the BPF verifier<br /> verifies the arguments of global function arguments, specifically<br /> those which take an argument of type ARG_PTR_TO_DYNPTR |<br /> MEM_RDONLY. Also, process_dynptr_func() doesn&amp;#39;t appear to perform any<br /> explicit and strict type matching on the supplied register type, so<br /> let&amp;#39;s also enforce that a register either type PTR_TO_STACK or<br /> CONST_PTR_TO_DYNPTR is by the caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme: apple: fix device reference counting<br /> <br /> Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl.<br /> Split the allocation side out to make the error handling boundary easier<br /> to navigate. The apple driver had been doing this wrong, leaking the<br /> controller device memory on a tagset failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix UAFs when destroying the queues<br /> <br /> The second tagged commit started sometimes (very rarely, but possible)<br /> throwing WARNs from<br /> net/core/page_pool.c:page_pool_disable_direct_recycling().<br /> Turned out idpf frees interrupt vectors with embedded NAPIs *before*<br /> freeing the queues making page_pools&amp;#39; NAPI pointers lead to freed<br /> memory before these pools are destroyed by libeth.<br /> It&amp;#39;s not clear whether there are other accesses to the freed vectors<br /> when destroying the queues, but anyway, we usually free queue/interrupt<br /> vectors only when the queues are destroyed and the NAPIs are guaranteed<br /> to not be referenced anywhere.<br /> <br /> Invert the allocation and freeing logic making queue/interrupt vectors<br /> be allocated first and freed last. Vectors don&amp;#39;t require queues to be<br /> present, so this is safe. Additionally, this change allows to remove<br /> that useless queue-&gt;q_vector pointer cleanup, as vectors are still<br /> valid when freeing the queues (+ both are freed within one function,<br /> so it&amp;#39;s not clear why nullify the pointers at all).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en : Fix memory out-of-bounds in bnxt_fill_hw_rss_tbl()<br /> <br /> A recent commit has modified the code in __bnxt_reserve_rings() to<br /> set the default RSS indirection table to default only when the number<br /> of RX rings is changing. While this works for newer firmware that<br /> requires RX ring reservations, it causes the regression on older<br /> firmware not requiring RX ring resrvations (BNXT_NEW_RM() returns<br /> false).<br /> <br /> With older firmware, RX ring reservations are not required and so<br /> hw_resc-&gt;resv_rx_rings is not always set to the proper value. The<br /> comparison:<br /> <br /> if (old_rx_rings != bp-&gt;hw_resc.resv_rx_rings)<br /> <br /> in __bnxt_reserve_rings() may be false even when the RX rings are<br /> changing. This will cause __bnxt_reserve_rings() to skip setting<br /> the default RSS indirection table to default to match the current<br /> number of RX rings. This may later cause bnxt_fill_hw_rss_tbl() to<br /> use an out-of-range index.<br /> <br /> We already have bnxt_check_rss_tbl_no_rmgr() to handle exactly this<br /> scenario. We just need to move it up in bnxt_need_reserve_rings()<br /> to be called unconditionally when using older firmware. Without the<br /> fix, if the TX rings are changing, we&amp;#39;ll skip the<br /> bnxt_check_rss_tbl_no_rmgr() call and __bnxt_reserve_rings() may also<br /> skip the bnxt_set_dflt_rss_indir_tbl() call for the reason explained<br /> in the last paragraph. Without setting the default RSS indirection<br /> table to default, it causes the regression:<br /> <br /> BUG: KASAN: slab-out-of-bounds in __bnxt_hwrm_vnic_set_rss+0xb79/0xe40<br /> Read of size 2 at addr ffff8881c5809618 by task ethtool/31525<br /> Call Trace:<br /> __bnxt_hwrm_vnic_set_rss+0xb79/0xe40<br /> bnxt_hwrm_vnic_rss_cfg_p5+0xf7/0x460<br /> __bnxt_setup_vnic_p5+0x12e/0x270<br /> __bnxt_open_nic+0x2262/0x2f30<br /> bnxt_open_nic+0x5d/0xf0<br /> ethnl_set_channels+0x5d4/0xb30<br /> ethnl_default_set_doit+0x2f1/0x620

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: rt5033: Bring back i2c_set_clientdata<br /> <br /> Commit 3a93da231c12 ("power: supply: rt5033: Use devm_power_supply_register() helper")<br /> reworked the driver to use devm. While at it, the i2c_set_clientdata<br /> was dropped along with the remove callback. Unfortunately other parts<br /> of the driver also rely on i2c clientdata so this causes kernel oops.<br /> <br /> Bring the call back to fix the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: intel-vbtn: Protect ACPI notify handler against recursion<br /> <br /> Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on<br /> all CPUs") ACPI notify handlers like the intel-vbtn notify_handler() may<br /> run on multiple CPU cores racing with themselves.<br /> <br /> This race gets hit on Dell Venue 7140 tablets when undocking from<br /> the keyboard, causing the handler to try and register priv-&gt;switches_dev<br /> twice, as can be seen from the dev_info() message getting logged twice:<br /> <br /> [ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event<br /> [ 83.861858] input: Intel Virtual Switches as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17<br /> [ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event<br /> <br /> After which things go seriously wrong:<br /> [ 83.861872] sysfs: cannot create duplicate filename &amp;#39;/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17&amp;#39;<br /> ...<br /> [ 83.861967] kobject: kobject_add_internal failed for input17 with -EEXIST, don&amp;#39;t try to register things with the same name in the same directory.<br /> [ 83.877338] BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> ...<br /> <br /> Protect intel-vbtn notify_handler() from racing with itself with a mutex<br /> to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules<br /> <br /> Check the pointer value to fix potential null pointer<br /> dereference

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix the null pointer dereference to ras_manager<br /> <br /> Check ras_manager before using it

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/pm: Fix the null pointer dereference for smu7<br /> <br /> optimize the code to avoid pass a null pointer (hwmgr-&gt;backend)<br /> to function smu7_update_edc_leakage_table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix NULL dereference at band check in starting tx ba session<br /> <br /> In MLD connection, link_data/link_conf are dynamically allocated. They<br /> don&amp;#39;t point to vif-&gt;bss_conf. So, there will be no chanreq assigned to<br /> vif-&gt;bss_conf and then the chan will be NULL. Tweak the code to check<br /> ht_supported/vht_supported/has_he/has_eht on sta deflink.<br /> <br /> Crash log (with rtw89 version under MLO development):<br /> [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 9890.526102] #PF: supervisor read access in kernel mode<br /> [ 9890.526105] #PF: error_code(0x0000) - not-present page<br /> [ 9890.526109] PGD 0 P4D 0<br /> [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1<br /> [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018<br /> [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core]<br /> [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211<br /> [ 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 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3<br /> All code<br /> ========<br /> 0: f7 e8 imul %eax<br /> 2: d5 (bad)<br /> 3: 93 xchg %eax,%ebx<br /> 4: 3e ea ds (bad)<br /> 6: 48 83 c4 28 add $0x28,%rsp<br /> a: 89 d8 mov %ebx,%eax<br /> c: 5b pop %rbx<br /> d: 41 5c pop %r12<br /> f: 41 5d pop %r13<br /> 11: 41 5e pop %r14<br /> 13: 41 5f pop %r15<br /> 15: 5d pop %rbp<br /> 16: c3 retq<br /> 17: cc int3<br /> 18: cc int3<br /> 19: cc int3<br /> 1a: cc int3<br /> 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax<br /> 22: ff<br /> 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax<br /> 2a:* 83 38 03 cmpl $0x3,(%rax)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: disallow setting special AP channel widths<br /> <br /> Setting the AP channel width is meant for use with the normal<br /> 20/40/... MHz channel width progression, and switching around<br /> in S1G or narrow channels isn&amp;#39;t supported. Disallow that.