Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix potential deadlock when releasing mids<br /> <br /> All release_mid() callers seem to hold a reference of @mid so there is<br /> no need to call kref_put(&amp;mid-&gt;refcount, __release_mid) under<br /> @server-&gt;mid_lock spinlock. If they don&amp;#39;t, then an use-after-free bug<br /> would have occurred anyways.<br /> <br /> By getting rid of such spinlock also fixes a potential deadlock as<br /> shown below<br /> <br /> CPU 0 CPU 1<br /> ------------------------------------------------------------------<br /> cifs_demultiplex_thread() cifs_debug_data_proc_show()<br /> release_mid()<br /> spin_lock(&amp;server-&gt;mid_lock);<br /> spin_lock(&amp;cifs_tcp_ses_lock)<br /> spin_lock(&amp;server-&gt;mid_lock)<br /> __release_mid()<br /> smb2_find_smb_tcon()<br /> spin_lock(&amp;cifs_tcp_ses_lock) *deadlock*

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix use-after-free in rdata-&gt;read_into_pages()<br /> <br /> When the network status is unstable, use-after-free may occur when<br /> read data from the server.<br /> <br /> BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x38/0x4c<br /> print_report+0x16f/0x4a6<br /> kasan_report+0xb7/0x130<br /> readpages_fill_pages+0x14c/0x7e0<br /> cifs_readv_receive+0x46d/0xa40<br /> cifs_demultiplex_thread+0x121c/0x1490<br /> kthread+0x16b/0x1a0<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> Allocated by task 2535:<br /> kasan_save_stack+0x22/0x50<br /> kasan_set_track+0x25/0x30<br /> __kasan_kmalloc+0x82/0x90<br /> cifs_readdata_direct_alloc+0x2c/0x110<br /> cifs_readdata_alloc+0x2d/0x60<br /> cifs_readahead+0x393/0xfe0<br /> read_pages+0x12f/0x470<br /> page_cache_ra_unbounded+0x1b1/0x240<br /> filemap_get_pages+0x1c8/0x9a0<br /> filemap_read+0x1c0/0x540<br /> cifs_strict_readv+0x21b/0x240<br /> vfs_read+0x395/0x4b0<br /> ksys_read+0xb8/0x150<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Freed by task 79:<br /> kasan_save_stack+0x22/0x50<br /> kasan_set_track+0x25/0x30<br /> kasan_save_free_info+0x2e/0x50<br /> __kasan_slab_free+0x10e/0x1a0<br /> __kmem_cache_free+0x7a/0x1a0<br /> cifs_readdata_release+0x49/0x60<br /> process_one_work+0x46c/0x760<br /> worker_thread+0x2a4/0x6f0<br /> kthread+0x16b/0x1a0<br /> ret_from_fork+0x2c/0x50<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x22/0x50<br /> __kasan_record_aux_stack+0x95/0xb0<br /> insert_work+0x2b/0x130<br /> __queue_work+0x1fe/0x660<br /> queue_work_on+0x4b/0x60<br /> smb2_readv_callback+0x396/0x800<br /> cifs_abort_connection+0x474/0x6a0<br /> cifs_reconnect+0x5cb/0xa50<br /> cifs_readv_from_socket.cold+0x22/0x6c<br /> cifs_read_page_from_socket+0xc1/0x100<br /> readpages_fill_pages.cold+0x2f/0x46<br /> cifs_readv_receive+0x46d/0xa40<br /> cifs_demultiplex_thread+0x121c/0x1490<br /> kthread+0x16b/0x1a0<br /> ret_from_fork+0x2c/0x50<br /> <br /> The following function calls will cause UAF of the rdata pointer.<br /> <br /> readpages_fill_pages<br /> cifs_read_page_from_socket<br /> cifs_readv_from_socket<br /> cifs_reconnect<br /> __cifs_reconnect<br /> cifs_abort_connection<br /> mid-&gt;callback() --&gt; smb2_readv_callback<br /> queue_work(&amp;rdata-&gt;work) # if the worker completes first,<br /> # the rdata is freed<br /> cifs_readv_complete<br /> kref_put<br /> cifs_readdata_release<br /> kfree(rdata)<br /> return rdata-&gt;... # UAF in readpages_fill_pages()<br /> <br /> Similarly, this problem also occurs in the uncache_fill_pages().<br /> <br /> Fix this by adjusts the order of condition judgment in the return<br /> statement.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: USB: Fix wrong-direction WARNING in plusb.c<br /> <br /> The syzbot fuzzer detected a bug in the plusb network driver: A<br /> zero-length control-OUT transfer was treated as a read instead of a<br /> write. In modern kernels this error provokes a WARNING:<br /> <br /> usb 1-1: BOGUS control dir, pipe 80000280 doesn&amp;#39;t match bRequestType c0<br /> WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411<br /> usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411<br /> Modules linked in:<br /> CPU: 1 PID: 4645 Comm: dhcpcd Not tainted<br /> 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google<br /> 01/12/2023<br /> RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411<br /> ...<br /> Call Trace:<br /> <br /> usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58<br /> usb_internal_control_msg drivers/usb/core/message.c:102 [inline]<br /> usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153<br /> __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010<br /> usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068<br /> pl_vendor_req drivers/net/usb/plusb.c:60 [inline]<br /> pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]<br /> pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85<br /> usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889<br /> __dev_open+0x297/0x4d0 net/core/dev.c:1417<br /> __dev_change_flags+0x587/0x750 net/core/dev.c:8530<br /> dev_change_flags+0x97/0x170 net/core/dev.c:8602<br /> devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147<br /> inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979<br /> sock_do_ioctl+0xcc/0x230 net/socket.c:1169<br /> sock_ioctl+0x1f8/0x680 net/socket.c:1286<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and<br /> remove the USB_DIR_IN flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Do not use WQ_MEM_RECLAIM flag for workqueue<br /> <br /> When both ice and the irdma driver are loaded, a warning in<br /> check_flush_dependency is being triggered. This is due to ice driver<br /> workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one<br /> is not.<br /> <br /> According to kernel documentation, this flag should be set if the<br /> workqueue will be involved in the kernel&amp;#39;s memory reclamation flow.<br /> Since it is not, there is no need for the ice driver&amp;#39;s WQ to have this<br /> flag set so remove it.<br /> <br /> Example trace:<br /> <br /> [ +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0<br /> [ +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0<br /> [ +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha<br /> in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel<br /> _rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1<br /> 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_<br /> core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs<br /> ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter<br /> acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba<br /> ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse<br /> [ +0.000161] [last unloaded: bonding]<br /> [ +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1<br /> [ +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020<br /> [ +0.000003] Workqueue: ice ice_service_task [ice]<br /> [ +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0<br /> [ +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08<br /> 9f e8 bb d3 07 01 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06<br /> [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282<br /> [ +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000<br /> [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80<br /> [ +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112<br /> [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000<br /> [ +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400<br /> [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000<br /> [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0<br /> [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ +0.000002] PKRU: 55555554<br /> [ +0.000003] Call Trace:<br /> [ +0.000002] <br /> [ +0.000003] __flush_workqueue+0x203/0x840<br /> [ +0.000006] ? mutex_unlock+0x84/0xd0<br /> [ +0.000008] ? __pfx_mutex_unlock+0x10/0x10<br /> [ +0.000004] ? __pfx___flush_workqueue+0x10/0x10<br /> [ +0.000006] ? mutex_lock+0xa3/0xf0<br /> [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core]<br /> [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core]<br /> [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core]<br /> [ +0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma]<br /> [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]<br /> [ +0.000059] ? up_write+0x5c/0x90<br /> [ +0.000005] irdma_remove+0x36/0x90 [irdma]<br /> [ +0.000062] auxiliary_bus_remove+0x32/0x50<br /> [ +0.000007] device_r<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix potential NULL-ptr-dereference<br /> <br /> in_dev_get() can return NULL which will cause a failure once idev is<br /> dereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a<br /> check for NULL value in idev beforehand.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/IPoIB: Fix legacy IPoIB due to wrong number of queues<br /> <br /> The cited commit creates child PKEY interfaces over netlink will<br /> multiple tx and rx queues, but some devices doesn&amp;#39;t support more than 1<br /> tx and 1 rx queues. This causes to a crash when traffic is sent over the<br /> PKEY interface due to the parent having a single queue but the child<br /> having multiple queues.<br /> <br /> This patch fixes the number of queues to 1 for legacy IPoIB at the<br /> earliest possible point in time.<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000036b<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:kmem_cache_alloc+0xcb/0x450<br /> Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a<br /> 01 49 8b 3c 24 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b<br /> RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202<br /> RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae<br /> RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00<br /> RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40<br /> R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000<br /> R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000<br /> FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> skb_clone+0x55/0xd0<br /> ip6_finish_output2+0x3fe/0x690<br /> ip6_finish_output+0xfa/0x310<br /> ip6_send_skb+0x1e/0x60<br /> udp_v6_send_skb+0x1e5/0x420<br /> udpv6_sendmsg+0xb3c/0xe60<br /> ? ip_mc_finish_output+0x180/0x180<br /> ? __switch_to_asm+0x3a/0x60<br /> ? __switch_to_asm+0x34/0x60<br /> sock_sendmsg+0x33/0x40<br /> __sys_sendto+0x103/0x160<br /> ? _copy_to_user+0x21/0x30<br /> ? kvm_clock_get_cycles+0xd/0x10<br /> ? ktime_get_ts64+0x49/0xe0<br /> __x64_sys_sendto+0x25/0x30<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f9374f1ed14<br /> Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b<br /> 7c 24 08 0f 05 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b<br /> RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14<br /> RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030<br /> RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c<br /> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000<br /> R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()<br /> <br /> int type = nla_type(nla);<br /> <br /> if (type &gt; XFRMA_MAX) {<br /> return -EOPNOTSUPP;<br /> }<br /> <br /> @type is then used as an array index and can be used<br /> as a Spectre v1 gadget.<br /> <br /> if (nla_len(nla)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/hfi1: Restore allocated resources on failed copyout<br /> <br /> Fix a resource leak if an error occurs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: avoid format-overflow warning<br /> <br /> With gcc and W=1 option, there&amp;#39;s a warning like this:<br /> <br /> fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’:<br /> fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between<br /> 1 and 7 bytes into a region of size between 5 and 8<br /> [-Werror=format-overflow=]<br /> 1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev),<br /> MINOR(dev));<br /> | ^~<br /> <br /> String "f2fs_page_array_entry-%u:%u" can up to 35. The first "%u" can up<br /> to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35".<br /> slab_name&amp;#39;s size should be 35 rather than 32.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: Fix null dereference on suspend<br /> <br /> A race condition exists where a synchronous (noqueue) transfer can be<br /> active during a system suspend. This can cause a null pointer<br /> dereference exception to occur when the system resumes.<br /> <br /> Example order of events leading to the exception:<br /> 1. spi_sync() calls __spi_transfer_message_noqueue() which sets<br /> ctlr-&gt;cur_msg<br /> 2. Spi transfer begins via spi_transfer_one_message()<br /> 3. System is suspended interrupting the transfer context<br /> 4. System is resumed<br /> 6. spi_controller_resume() calls spi_start_queue() which resets cur_msg<br /> to NULL<br /> 7. Spi transfer context resumes and spi_finalize_current_message() is<br /> called which dereferences cur_msg (which is now NULL)<br /> <br /> Wait for synchronous transfers to complete before suspending by<br /> acquiring the bus mutex and setting/checking a suspend flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer<br /> <br /> Prior to LLVM 15.0.0, LLVM&amp;#39;s integrated assembler would incorrectly<br /> byte-swap NOP when compiling for big-endian, and the resulting series of<br /> bytes happened to match the encoding of FNMADD S21, S30, S0, S0.<br /> <br /> This went unnoticed until commit:<br /> <br /> 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")<br /> <br /> Prior to that commit, the kernel would always enable the use of FPSIMD<br /> early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of<br /> FNMADD within the kernel was not detected, but could result in the<br /> corruption of user or kernel FPSIMD state.<br /> <br /> After that commit, the instructions happen to trap during boot prior to<br /> FPSIMD being detected and enabled, e.g.<br /> <br /> | Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD<br /> | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> | pc : __pi_strcmp+0x1c/0x150<br /> | lr : populate_properties+0xe4/0x254<br /> | sp : ffffd014173d3ad0<br /> | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000<br /> | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008<br /> | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044<br /> | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005<br /> | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000<br /> | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000<br /> | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000<br /> | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000<br /> | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a<br /> | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8<br /> | Kernel panic - not syncing: Unhandled exception<br /> | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1<br /> | Hardware name: linux,dummy-virt (DT)<br /> | Call trace:<br /> | dump_backtrace+0xec/0x108<br /> | show_stack+0x18/0x2c<br /> | dump_stack_lvl+0x50/0x68<br /> | dump_stack+0x18/0x24<br /> | panic+0x13c/0x340<br /> | el1t_64_irq_handler+0x0/0x1c<br /> | el1_abort+0x0/0x5c<br /> | el1h_64_sync+0x64/0x68<br /> | __pi_strcmp+0x1c/0x150<br /> | unflatten_dt_nodes+0x1e8/0x2d8<br /> | __unflatten_device_tree+0x5c/0x15c<br /> | unflatten_device_tree+0x38/0x50<br /> | setup_arch+0x164/0x1e0<br /> | start_kernel+0x64/0x38c<br /> | __primary_switched+0xbc/0xc4<br /> <br /> Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is<br /> either GNU as or LLVM&amp;#39;s IAS 15.0.0 and newer, which contains the linked<br /> commit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix use-after-free in smb2_query_info_compound()<br /> <br /> The following UAF was triggered when running fstests generic/072 with<br /> KASAN enabled against Windows Server 2022 and mount options<br /> &amp;#39;multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm&amp;#39;<br /> <br /> BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> Read of size 8 at addr ffff888014941048 by task xfs_io/27534<br /> <br /> CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> Call Trace:<br /> dump_stack_lvl+0x4a/0x80<br /> print_report+0xcf/0x650<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __phys_addr+0x46/0x90<br /> kasan_report+0xda/0x110<br /> ? smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> ? smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> smb2_query_info_compound+0x423/0x6d0 [cifs]<br /> ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs]<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __stack_depot_save+0x39/0x480<br /> ? kasan_save_stack+0x33/0x60<br /> ? kasan_set_track+0x25/0x30<br /> ? ____kasan_slab_free+0x126/0x170<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> ? __pfx_smb2_queryfs+0x10/0x10 [cifs]<br /> ? __pfx___lock_acquire+0x10/0x10<br /> smb311_queryfs+0x210/0x220 [cifs]<br /> ? __pfx_smb311_queryfs+0x10/0x10 [cifs]<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? __lock_acquire+0x480/0x26c0<br /> ? lock_release+0x1ed/0x640<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? do_raw_spin_unlock+0x9b/0x100<br /> cifs_statfs+0x18c/0x4b0 [cifs]<br /> statfs_by_dentry+0x9b/0xf0<br /> fd_statfs+0x4e/0xb0<br /> __do_sys_fstatfs+0x7f/0xe0<br /> ? __pfx___do_sys_fstatfs+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> ? lockdep_hardirqs_on_prepare+0x136/0x200<br /> ? srso_alias_return_thunk+0x5/0x7f<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Allocated by task 27534:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> open_cached_dir+0x71b/0x1240 [cifs]<br /> smb2_query_info_compound+0x5c3/0x6d0 [cifs]<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> smb311_queryfs+0x210/0x220 [cifs]<br /> cifs_statfs+0x18c/0x4b0 [cifs]<br /> statfs_by_dentry+0x9b/0xf0<br /> fd_statfs+0x4e/0xb0<br /> __do_sys_fstatfs+0x7f/0xe0<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 27534:<br /> kasan_save_stack+0x33/0x60<br /> kasan_set_track+0x25/0x30<br /> kasan_save_free_info+0x2b/0x50<br /> ____kasan_slab_free+0x126/0x170<br /> slab_free_freelist_hook+0xd0/0x1e0<br /> __kmem_cache_free+0x9d/0x1b0<br /> open_cached_dir+0xff5/0x1240 [cifs]<br /> smb2_query_info_compound+0x5c3/0x6d0 [cifs]<br /> smb2_queryfs+0xc2/0x2c0 [cifs]<br /> <br /> This is a race between open_cached_dir() and cached_dir_lease_break()<br /> where the cache entry for the open directory handle receives a lease<br /> break while creating it. And before returning from open_cached_dir(),<br /> we put the last reference of the new @cfid because of<br /> !@cfid-&gt;has_lease.<br /> <br /> Besides the UAF, while running xfstests a lot of missed lease breaks<br /> have been noticed in tests that run several concurrent statfs(2) calls<br /> on those cached fids<br /> <br /> CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...<br /> CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...<br /> CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108<br /> CIFS: VFS: Dump pending requests:<br /> CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...<br /> CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...<br /> CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108<br /> ...<br /> <br /> To fix both, in open_cached_dir() ensure that @cfid-&gt;has_lease is set<br /> right before sending out compounded request so that any potential<br /> lease break will be get processed by demultiplex thread while we&amp;#39;re<br /> still caching @cfid. And, if open failed for some reason, re-check<br /> @cfid-&gt;has_lease to decide whether or not put lease reference.