Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fou: remove warn in gue_gro_receive on unsupported protocol<br /> <br /> Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is<br /> not known or does not have a GRO handler.<br /> <br /> Such a packet is easily constructed. Syzbot generates them and sets<br /> off this warning.<br /> <br /> Remove the warning as it is expected and not actionable.<br /> <br /> The warning was previously reduced from WARN_ON to WARN_ON_ONCE in<br /> commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad<br /> proto callbacks").

The Xiaomi router AX9000 has a post-authentication command injection vulnerability. This vulnerability is caused by the lack of input filtering, allowing an attacker to exploit it to obtain root access to the device.

Acrobat Reader versions 127.0.2651.105 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Tenda AX1806 v1.0.0.1 contains a stack overflow via the serverName parameter in the function form_fast_setting_internet_set.

Tenda AX1806 v1.0.0.1 contains a stack overflow via the iptv.stb.port parameter in the function setIptvInfo.

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.