Vulnerabilities

Intermediate register values of secure workloads can be exfiltrated in workloads scheduled from applications running in the non-secure environment of a platform.

A path traversal vulnerability in NETGEAR WiFi range extenders allows<br /> an attacker with LAN authentication to access the router&amp;#39;s IP and <br /> review the contents of the dynamically generated webproc file, which <br /> records the username and password submitted to the router GUI.

An insufficient authentication vulnerability in NETGEAR WiFi range <br /> extenders allows a network adjacent attacker with WiFi authentication or<br /> a physical Ethernet port connection to bypass the authentication <br /> process and access the admin panel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: hp-bioscfg: Fix out-of-bounds array access in ACPI package parsing<br /> <br /> The hp_populate_*_elements_from_package() functions in the hp-bioscfg<br /> driver contain out-of-bounds array access vulnerabilities.<br /> <br /> These functions parse ACPI packages into internal data structures using<br /> a for loop with index variable &amp;#39;elem&amp;#39; that iterates through<br /> enum_obj/integer_obj/order_obj/password_obj/string_obj arrays.<br /> <br /> When processing multi-element fields like PREREQUISITES and<br /> ENUM_POSSIBLE_VALUES, these functions read multiple consecutive array<br /> elements using expressions like &amp;#39;enum_obj[elem + reqs]&amp;#39; and<br /> &amp;#39;enum_obj[elem + pos_values]&amp;#39; within nested loops.<br /> <br /> The bug is that the bounds check only validated elem, but did not consider<br /> the additional offset when accessing elem + reqs or elem + pos_values.<br /> <br /> The fix changes the bounds check to validate the actual accessed index.

An insufficient input validation vulnerability in NETGEAR Orbi routers <br /> allows attackers connected to the router&amp;#39;s LAN to execute OS command <br /> injections.

An insufficient input validation vulnerability in NETGEAR Orbi devices&amp;#39; <br /> DHCPv6 functionality allows network adjacent attackers authenticated <br /> over WiFi or on LAN to execute OS command injections on the router. <br /> DHCPv6 is not enabled by default.

An authentication bypass vulnerability in NETGEAR Orbi devices allows <br /> users connected to the local network to access the router web interface <br /> as an admin.

An insufficient input validation vulnerability in the NETGEAR XR1000v2 <br /> allows attackers connected to the router&amp;#39;s LAN to execute OS command <br /> injections.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: fix the crash issue for zero copy XDP_TX action<br /> <br /> There is a crash issue when running zero copy XDP_TX action, the crash<br /> log is shown below.<br /> <br /> [ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000<br /> [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP<br /> [ 216.301694] Call trace:<br /> [ 216.304130] dcache_clean_poc+0x20/0x38 (P)<br /> [ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0<br /> [ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400<br /> [ 216.317701] __stmmac_xdp_run_prog+0x164/0x368<br /> [ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00<br /> [ 216.326576] __napi_poll+0x40/0x218<br /> [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> <br /> For XDP_TX action, the xdp_buff is converted to xdp_frame by<br /> xdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame<br /> depends on the memory type of the xdp_buff. For page pool based xdp_buff<br /> it produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy<br /> XSK pool based xdp_buff it produces xdp_frame with memory type<br /> MEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check the<br /> memory type and always uses the page pool type, this leads to invalid<br /> mappings and causes the crash. Therefore, check the xdp_buff memory type<br /> in stmmac_xdp_xmit_back() to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()<br /> <br /> In xe_oa_add_config_ioctl(), we accessed oa_config-&gt;id after dropping<br /> metrics_lock. Since this lock protects the lifetime of oa_config, an<br /> attacker could guess the id and call xe_oa_remove_config_ioctl() with<br /> perfect timing, freeing oa_config before we dereference it, leading to<br /> a potential use-after-free.<br /> <br /> Fix this by caching the id in a local variable while holding the lock.<br /> <br /> v2: (Matt A)<br /> - Dropped mutex_unlock(&amp;oa-&gt;metrics_lock) ordering change from<br /> xe_oa_remove_config_ioctl()<br /> <br /> (cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: 8192cu: fix tid out of range in rtl92cu_tx_fill_desc()<br /> <br /> TID getting from ieee80211_get_tid() might be out of range of array size<br /> of sta_entry-&gt;tids[], so check TID is less than MAX_TID_COUNT. Othwerwise,<br /> UBSAN warn:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:514:30<br /> index 10 is out of range for type &amp;#39;rtl_tid_data [9]&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> e1000: fix OOB in e1000_tbi_should_accept()<br /> <br /> In e1000_tbi_should_accept() we read the last byte of the frame via<br /> &amp;#39;data[length - 1]&amp;#39; to evaluate the TBI workaround. If the descriptor-<br /> reported length is zero or larger than the actual RX buffer size, this<br /> read goes out of bounds and can hit unrelated slab objects. The issue<br /> is observed from the NAPI receive path (e1000_clean_rx_irq):<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790<br /> Read of size 1 at addr ffff888014114e54 by task sshd/363<br /> <br /> CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5a/0x74<br /> print_address_description+0x7b/0x440<br /> print_report+0x101/0x200<br /> kasan_report+0xc1/0xf0<br /> e1000_tbi_should_accept+0x610/0x790<br /> e1000_clean_rx_irq+0xa8c/0x1110<br /> e1000_clean+0xde2/0x3c10<br /> __napi_poll+0x98/0x380<br /> net_rx_action+0x491/0xa20<br /> __do_softirq+0x2c9/0x61d<br /> do_softirq+0xd1/0x120<br /> <br /> <br /> __local_bh_enable_ip+0xfe/0x130<br /> ip_finish_output2+0x7d5/0xb00<br /> __ip_queue_xmit+0xe24/0x1ab0<br /> __tcp_transmit_skb+0x1bcb/0x3340<br /> tcp_write_xmit+0x175d/0x6bd0<br /> __tcp_push_pending_frames+0x7b/0x280<br /> tcp_sendmsg_locked+0x2e4f/0x32d0<br /> tcp_sendmsg+0x24/0x40<br /> sock_write_iter+0x322/0x430<br /> vfs_write+0x56c/0xa60<br /> ksys_write+0xd1/0x190<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f511b476b10<br /> Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24<br /> RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10<br /> RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003<br /> RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00<br /> R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003<br /> <br /> Allocated by task 1:<br /> __kasan_krealloc+0x131/0x1c0<br /> krealloc+0x90/0xc0<br /> add_sysfs_param+0xcb/0x8a0<br /> kernel_add_sysfs_param+0x81/0xd4<br /> param_sysfs_builtin+0x138/0x1a6<br /> param_sysfs_init+0x57/0x5b<br /> do_one_initcall+0x104/0x250<br /> do_initcall_level+0x102/0x132<br /> do_initcalls+0x46/0x74<br /> kernel_init_freeable+0x28f/0x393<br /> kernel_init+0x14/0x1a0<br /> ret_from_fork+0x22/0x30<br /> The buggy address belongs to the object at ffff888014114000<br /> which belongs to the cache kmalloc-2k of size 2048<br /> The buggy address is located 1620 bytes to the right of<br /> 2048-byte region [ffff888014114000, ffff888014114800]<br /> The buggy address belongs to the physical page:<br /> page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110<br /> head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0<br /> flags: 0x100000000010200(slab|head|node=0|zone=1)<br /> raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000<br /> raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> ==================================================================<br /> <br /> This happens because the TBI check unconditionally dereferences the last<br /> byte without validating the reported length first:<br /> <br /> u8 last_byte = *(data + length - 1);<br /> <br /> Fix by rejecting the frame early if the length is zero, or if it exceeds<br /> adapter-&gt;rx_buffer_len. This preserves the TBI workaround semantics for<br /> valid frames and prevents touching memory beyond the RX buffer.