Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix RX buf alloc_size alignment and atomic op panic<br /> <br /> The MANA driver&amp;#39;s RX buffer alloc_size is passed into napi_build_skb() to<br /> create SKB. skb_shinfo(skb) is located at the end of skb, and its alignment<br /> is affected by the alloc_size passed into napi_build_skb(). The size needs<br /> to be aligned properly for better performance and atomic operations.<br /> Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic<br /> operations may panic on the skb_shinfo(skb)-&gt;dataref due to alignment fault.<br /> <br /> To fix this bug, add proper alignment to the alloc_size calculation.<br /> <br /> Sample panic info:<br /> [ 253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce<br /> [ 253.300900] Mem abort info:<br /> [ 253.301760] ESR = 0x0000000096000021<br /> [ 253.302825] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 253.304268] SET = 0, FnV = 0<br /> [ 253.305172] EA = 0, S1PTW = 0<br /> [ 253.306103] FSC = 0x21: alignment fault<br /> Call trace:<br /> __skb_clone+0xfc/0x198<br /> skb_clone+0x78/0xe0<br /> raw6_local_deliver+0xfc/0x228<br /> ip6_protocol_deliver_rcu+0x80/0x500<br /> ip6_input_finish+0x48/0x80<br /> ip6_input+0x48/0xc0<br /> ip6_sublist_rcv_finish+0x50/0x78<br /> ip6_sublist_rcv+0x1cc/0x2b8<br /> ipv6_list_rcv+0x100/0x150<br /> __netif_receive_skb_list_core+0x180/0x220<br /> netif_receive_skb_list_internal+0x198/0x2a8<br /> __napi_poll+0x138/0x250<br /> net_rx_action+0x148/0x330<br /> handle_softirqs+0x12c/0x3a0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix xfrm real_dev null pointer dereference<br /> <br /> We shouldn&amp;#39;t set real_dev to NULL because packets can be in transit and<br /> xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume<br /> real_dev is set.<br /> <br /> Example trace:<br /> kernel: BUG: unable to handle page fault for address: 0000000000001030<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: #PF: supervisor write access in kernel mode<br /> kernel: #PF: error_code(0x0002) - not-present page<br /> kernel: PGD 0 P4D 0<br /> kernel: Oops: 0002 [#1] PREEMPT SMP<br /> kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12<br /> kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel:<br /> kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60<br /> kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00<br /> kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014<br /> kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000<br /> kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000<br /> kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000<br /> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: ? __die+0x1f/0x60<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: ? page_fault_oops+0x142/0x4c0<br /> kernel: ? do_user_addr_fault+0x65/0x670<br /> kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: ? exc_page_fault+0x7b/0x180<br /> kernel: ? asm_exc_page_fault+0x22/0x30<br /> kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim]<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]<br /> kernel: bond0: (slave eni0np1): making interface the new active one<br /> kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding]<br /> kernel: xfrm_output+0x61/0x3b0<br /> kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA<br /> kernel: ip_push_pending_frames+0x56/0x80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix null pointer deref in bond_ipsec_offload_ok<br /> <br /> We must check if there is an active slave before dereferencing the pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: prevent concurrent execution of tcp_sk_exit_batch<br /> <br /> Its possible that two threads call tcp_sk_exit_batch() concurrently,<br /> once from the cleanup_net workqueue, once from a task that failed to clone<br /> a new netns. In the latter case, error unwinding calls the exit handlers<br /> in reverse order for the &amp;#39;failed&amp;#39; netns.<br /> <br /> tcp_sk_exit_batch() calls tcp_twsk_purge().<br /> Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"),<br /> this function picks up twsk in any dying netns, not just the one passed<br /> in via exit_batch list.<br /> <br /> This means that the error unwind of setup_net() can "steal" and destroy<br /> timewait sockets belonging to the exiting netns.<br /> <br /> This allows the netns exit worker to proceed to call<br /> <br /> WARN_ON_ONCE(!refcount_dec_and_test(&amp;net-&gt;ipv4.tcp_death_row.tw_refcount));<br /> <br /> without the expected 1 -&gt; 0 transition, which then splats.<br /> <br /> At same time, error unwind path that is also running inet_twsk_purge()<br /> will splat as well:<br /> <br /> WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210<br /> ...<br /> refcount_dec include/linux/refcount.h:351 [inline]<br /> inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70<br /> inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221<br /> inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304<br /> tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522<br /> ops_exit_list+0x128/0x180 net/core/net_namespace.c:178<br /> setup_net+0x714/0xb40 net/core/net_namespace.c:375<br /> copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508<br /> create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110<br /> <br /> ... because refcount_dec() of tw_refcount unexpectedly dropped to 0.<br /> <br /> This doesn&amp;#39;t seem like an actual bug (no tw sockets got lost and I don&amp;#39;t<br /> see a use-after-free) but as erroneous trigger of debug check.<br /> <br /> Add a mutex to force strict ordering: the task that calls tcp_twsk_purge()<br /> blocks other task from doing final _dec_and_test before mutex-owner has<br /> removed all tw sockets of dying netns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix a deadlock problem when config TC during resetting<br /> <br /> When config TC during the reset process, may cause a deadlock, the flow is<br /> as below:<br /> pf reset start<br /> │<br /> ▼<br /> ......<br /> setup tc │<br /> │ ▼<br /> ▼ DOWN: napi_disable()<br /> napi_disable()(skip) │<br /> │ │<br /> ▼ ▼<br /> ...... ......<br /> │ │<br /> ▼ │<br /> napi_enable() │<br /> ▼<br /> UINIT: netif_napi_del()<br /> │<br /> ▼<br /> ......<br /> │<br /> ▼<br /> INIT: netif_napi_add()<br /> │<br /> ▼<br /> ...... global reset start<br /> │ │<br /> ▼ ▼<br /> UP: napi_enable()(skip) ......<br /> │ │<br /> ▼ ▼<br /> ...... napi_disable()<br /> <br /> In reset process, the driver will DOWN the port and then UINIT, in this<br /> case, the setup tc process will UP the port before UINIT, so cause the<br /> problem. Adds a DOWN process in UINIT to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: idt77252: prevent use after free in dequeue_rx()<br /> <br /> We can&amp;#39;t dereference "skb" after calling vcc-&gt;push() because the skb<br /> is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gtp: pull network headers in gtp_dev_xmit()<br /> <br /> syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]<br /> <br /> We must make sure the IPv4 or Ipv6 header is pulled in skb-&gt;head<br /> before accessing fields in them.<br /> <br /> Use pskb_inet_may_pull() to fix this issue.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]<br /> BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]<br /> BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281<br /> ipv6_pdp_find drivers/net/gtp.c:220 [inline]<br /> gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]<br /> gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281<br /> __netdev_start_xmit include/linux/netdevice.h:4913 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4922 [inline]<br /> xmit_one net/core/dev.c:3580 [inline]<br /> dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596<br /> __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423<br /> dev_queue_xmit include/linux/netdevice.h:3105 [inline]<br /> packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3145 [inline]<br /> packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:745<br /> __sys_sendto+0x685/0x830 net/socket.c:2204<br /> __do_sys_sendto net/socket.c:2216 [inline]<br /> __se_sys_sendto net/socket.c:2212 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212<br /> x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:3994 [inline]<br /> slab_alloc_node mm/slub.c:4037 [inline]<br /> kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583<br /> __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674<br /> alloc_skb include/linux/skbuff.h:1320 [inline]<br /> alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526<br /> sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815<br /> packet_alloc_skb net/packet/af_packet.c:2994 [inline]<br /> packet_snd net/packet/af_packet.c:3088 [inline]<br /> packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:745<br /> __sys_sendto+0x685/0x830 net/socket.c:2204<br /> __do_sys_sendto net/socket.c:2216 [inline]<br /> __se_sys_sendto net/socket.c:2212 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212<br /> x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/netfs/fscache_cookie: add missing "n_accesses" check<br /> <br /> This fixes a NULL pointer dereference bug due to a data race which<br /> looks like this:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43<br /> Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018<br /> Workqueue: events_unbound netfs_rreq_write_to_cache_work<br /> RIP: 0010:cachefiles_prepare_write+0x30/0xa0<br /> Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10<br /> RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286<br /> RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000<br /> RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438<br /> RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001<br /> R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68<br /> R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00<br /> FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x15d/0x440<br /> ? search_module_extables+0xe/0x40<br /> ? fixup_exception+0x22/0x2f0<br /> ? exc_page_fault+0x5f/0x100<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? cachefiles_prepare_write+0x30/0xa0<br /> netfs_rreq_write_to_cache_work+0x135/0x2e0<br /> process_one_work+0x137/0x2c0<br /> worker_thread+0x2e9/0x400<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xcc/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x30/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> Modules linked in:<br /> CR2: 0000000000000008<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This happened because fscache_cookie_state_machine() was slow and was<br /> still running while another process invoked fscache_unuse_cookie();<br /> this led to a fscache_cookie_lru_do_one() call, setting the<br /> FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by<br /> fscache_cookie_state_machine(), withdrawing the cookie via<br /> cachefiles_withdraw_cookie(), clearing cookie-&gt;cache_priv.<br /> <br /> At the same time, yet another process invoked<br /> cachefiles_prepare_write(), which found a NULL pointer in this code<br /> line:<br /> <br /> struct cachefiles_object *object = cachefiles_cres_object(cres);<br /> <br /> The next line crashes, obviously:<br /> <br /> struct cachefiles_cache *cache = object-&gt;volume-&gt;cache;<br /> <br /> During cachefiles_prepare_write(), the "n_accesses" counter is<br /> non-zero (via fscache_begin_operation()). The cookie must not be<br /> withdrawn until it drops to zero.<br /> <br /> The counter is checked by fscache_cookie_state_machine() before<br /> switching to FSCACHE_COOKIE_STATE_RELINQUISHING and<br /> FSCACHE_COOKIE_STATE_WITHDRAWING (in "case<br /> FSCACHE_COOKIE_STATE_FAILED"), but not for<br /> FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case<br /> FSCACHE_COOKIE_STATE_ACTIVE").<br /> <br /> This patch adds the missing check. With a non-zero access counter,<br /> the function returns and the next fscache_end_cookie_access() call<br /> will queue another fscache_cookie_state_machine() call to handle the<br /> still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtla/osnoise: Prevent NULL dereference in error handling<br /> <br /> If the "tool-&gt;data" allocation fails then there is no need to call<br /> osnoise_free_top() and, in fact, doing so will lead to a NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfs: Don&amp;#39;t evict inode under the inode lru traversing context<br /> <br /> The inode reclaiming process(See function prune_icache_sb) collects all<br /> reclaimable inodes and mark them with I_FREEING flag at first, at that<br /> time, other processes will be stuck if they try getting these inodes<br /> (See function find_inode_fast), then the reclaiming process destroy the<br /> inodes by function dispose_list(). Some filesystems(eg. ext4 with<br /> ea_inode feature, ubifs with xattr) may do inode lookup in the inode<br /> evicting callback function, if the inode lookup is operated under the<br /> inode lru traversing context, deadlock problems may happen.<br /> <br /> Case 1: In function ext4_evict_inode(), the ea inode lookup could happen<br /> if ea_inode feature is enabled, the lookup process will be stuck<br /> under the evicting context like this:<br /> <br /> 1. File A has inode i_reg and an ea inode i_ea<br /> 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-&gt;i_ea<br /> 3. Then, following three processes running like this:<br /> <br /> PA PB<br /> echo 2 &gt; /proc/sys/vm/drop_caches<br /> shrink_slab<br /> prune_dcache_sb<br /> // i_reg is added into lru, lru-&gt;i_ea-&gt;i_reg<br /> prune_icache_sb<br /> list_lru_walk_one<br /> inode_lru_isolate<br /> i_ea-&gt;i_state |= I_FREEING // set inode state<br /> inode_lru_isolate<br /> __iget(i_reg)<br /> spin_unlock(&amp;i_reg-&gt;i_lock)<br /> spin_unlock(lru_lock)<br /> rm file A<br /> i_reg-&gt;nlink = 0<br /> iput(i_reg) // i_reg-&gt;nlink is 0, do evict<br /> ext4_evict_inode<br /> ext4_xattr_delete_inode<br /> ext4_xattr_inode_dec_ref_all<br /> ext4_xattr_inode_iget<br /> ext4_iget(i_ea-&gt;i_ino)<br /> iget_locked<br /> find_inode_fast<br /> __wait_on_freeing_inode(i_ea) ----→ AA deadlock<br /> dispose_list // cannot be executed by prune_icache_sb<br /> wake_up_bit(&amp;i_ea-&gt;i_state)<br /> <br /> Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file<br /> deleting process holds BASEHD&amp;#39;s wbuf-&gt;io_mutex while getting the<br /> xattr inode, which could race with inode reclaiming process(The<br /> reclaiming process could try locking BASEHD&amp;#39;s wbuf-&gt;io_mutex in<br /> inode evicting function), then an ABBA deadlock problem would<br /> happen as following:<br /> <br /> 1. File A has inode ia and a xattr(with inode ixa), regular file B has<br /> inode ib and a xattr.<br /> 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-&gt;ixa<br /> 3. Then, following three processes running like this:<br /> <br /> PA PB PC<br /> echo 2 &gt; /proc/sys/vm/drop_caches<br /> shrink_slab<br /> prune_dcache_sb<br /> // ib and ia are added into lru, lru-&gt;ixa-&gt;ib-&gt;ia<br /> prune_icache_sb<br /> list_lru_walk_one<br /> inode_lru_isolate<br /> ixa-&gt;i_state |= I_FREEING // set inode state<br /> inode_lru_isolate<br /> __iget(ib)<br /> spin_unlock(&amp;ib-&gt;i_lock)<br /> spin_unlock(lru_lock)<br /> rm file B<br /> ib-&gt;nlink = 0<br /> rm file A<br /> iput(ia)<br /> ubifs_evict_inode(ia)<br /> ubifs_jnl_delete_inode(ia)<br /> ubifs_jnl_write_inode(ia)<br /> make_reservation(BASEHD) // Lock wbuf-&gt;io_mutex<br /> ubifs_iget(ixa-&gt;i_ino)<br /> iget_locked<br /> find_inode_fast<br /> __wait_on_freeing_inode(ixa)<br /> | iput(ib) // ib-&gt;nlink is 0, do evict<br /> | ubifs_evict_inode<br /> | ubifs_jnl_delete_inode(ib)<br /> ↓ ubifs_jnl_write_inode<br /> ABBA deadlock ←-----make_reservation(BASEHD)<br /> dispose_list // cannot be executed by prune_icache_sb<br /> wake_up_bit(&amp;ixa-&gt;i_state)<br /> <br /> Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING<br /> to pin the inode in memory while inode_lru_isolate(<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration<br /> <br /> re-enumerating full-speed devices after a failed address device command<br /> can trigger a NULL pointer dereference.<br /> <br /> Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size<br /> value during enumeration. Usb core calls usb_ep0_reinit() in this case,<br /> which ends up calling xhci_configure_endpoint().<br /> <br /> On Panther point xHC the xhci_configure_endpoint() function will<br /> additionally check and reserve bandwidth in software. Other hosts do<br /> this in hardware<br /> <br /> If xHC address device command fails then a new xhci_virt_device structure<br /> is allocated as part of re-enabling the slot, but the bandwidth table<br /> pointers are not set up properly here.<br /> This triggers the NULL pointer dereference the next time usb_ep0_reinit()<br /> is called and xhci_configure_endpoint() tries to check and reserve<br /> bandwidth<br /> <br /> [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd<br /> [46710.713699] usb 3-1: Device not responding to setup address.<br /> [46710.917684] usb 3-1: Device not responding to setup address.<br /> [46711.125536] usb 3-1: device not accepting address 5, error -71<br /> [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [46711.125600] #PF: supervisor read access in kernel mode<br /> [46711.125603] #PF: error_code(0x0000) - not-present page<br /> [46711.125606] PGD 0 P4D 0<br /> [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI<br /> [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1<br /> [46711.125620] Hardware name: Gigabyte Technology Co., Ltd.<br /> [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]<br /> [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c<br /> <br /> Fix this by making sure bandwidth table pointers are set up correctly<br /> after a failed address device command, and additionally by avoiding<br /> checking for bandwidth in cases like this where no actual endpoints are<br /> added or removed, i.e. only context for default control endpoint 0 is<br /> evaluated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/cpuset: fix panic caused by partcmd_update<br /> <br /> We find a bug as below:<br /> BUG: unable to handle page fault for address: 00000003<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 PID: 358 Comm: bash Tainted: G W I 6.6.0-10893-g60d6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/4<br /> RIP: 0010:partition_sched_domains_locked+0x483/0x600<br /> Code: 01 48 85 d2 74 0d 48 83 05 29 3f f8 03 01 f3 48 0f bc c2 89 c0 48 9<br /> RSP: 0018:ffffc90000fdbc58 EFLAGS: 00000202<br /> RAX: 0000000100000003 RBX: ffff888100b3dfa0 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000002fe80<br /> RBP: ffff888100b3dfb0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffffc90000fdbcb0 R11: 0000000000000004 R12: 0000000000000002<br /> R13: ffff888100a92b48 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f44a5425740(0000) GS:ffff888237d80000(0000) knlGS:0000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000100030973 CR3: 000000010722c000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> ? show_regs+0x8c/0xa0<br /> ? __die_body+0x23/0xa0<br /> ? __die+0x3a/0x50<br /> ? page_fault_oops+0x1d2/0x5c0<br /> ? partition_sched_domains_locked+0x483/0x600<br /> ? search_module_extables+0x2a/0xb0<br /> ? search_exception_tables+0x67/0x90<br /> ? kernelmode_fixup_or_oops+0x144/0x1b0<br /> ? __bad_area_nosemaphore+0x211/0x360<br /> ? up_read+0x3b/0x50<br /> ? bad_area_nosemaphore+0x1a/0x30<br /> ? exc_page_fault+0x890/0xd90<br /> ? __lock_acquire.constprop.0+0x24f/0x8d0<br /> ? __lock_acquire.constprop.0+0x24f/0x8d0<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? partition_sched_domains_locked+0x483/0x600<br /> ? partition_sched_domains_locked+0xf0/0x600<br /> rebuild_sched_domains_locked+0x806/0xdc0<br /> update_partition_sd_lb+0x118/0x130<br /> cpuset_write_resmask+0xffc/0x1420<br /> cgroup_file_write+0xb2/0x290<br /> kernfs_fop_write_iter+0x194/0x290<br /> new_sync_write+0xeb/0x160<br /> vfs_write+0x16f/0x1d0<br /> ksys_write+0x81/0x180<br /> __x64_sys_write+0x21/0x30<br /> x64_sys_call+0x2f25/0x4630<br /> do_syscall_64+0x44/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> RIP: 0033:0x7f44a553c887<br /> <br /> It can be reproduced with cammands:<br /> cd /sys/fs/cgroup/<br /> mkdir test<br /> cd test/<br /> echo +cpuset &gt; ../cgroup.subtree_control<br /> echo root &gt; cpuset.cpus.partition<br /> cat /sys/fs/cgroup/cpuset.cpus.effective<br /> 0-3<br /> echo 0-3 &gt; cpuset.cpus // taking away all cpus from root<br /> <br /> This issue is caused by the incorrect rebuilding of scheduling domains.<br /> In this scenario, test/cpuset.cpus.partition should be an invalid root<br /> and should not trigger the rebuilding of scheduling domains. When calling<br /> update_parent_effective_cpumask with partcmd_update, if newmask is not<br /> null, it should recheck newmask whether there are cpus is available<br /> for parect/cs that has tasks.