Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix null pointer dereference in alloc_preauth_hash()<br /> <br /> The Client send malformed smb2 negotiate request. ksmbd return error<br /> response. Subsequently, the client can send smb2 session setup even<br /> thought conn-&gt;preauth_info is not allocated.<br /> This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore<br /> session setup request if smb2 negotiate phase is not complete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix overflow in dacloffset bounds check<br /> <br /> The dacloffset field was originally typed as int and used in an<br /> unchecked addition, which could overflow and bypass the existing<br /> bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().<br /> <br /> This could result in out-of-bounds memory access and a kernel crash<br /> when dereferencing the DACL pointer.<br /> <br /> This patch converts dacloffset to unsigned int and uses<br /> check_add_overflow() to validate access to the DACL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix use-after-free in print_graph_function_flags during tracer switching<br /> <br /> Kairui reported a UAF issue in print_graph_function_flags() during<br /> ftrace stress testing [1]. This issue can be reproduced if puting a<br /> &amp;#39;mdelay(10)&amp;#39; after &amp;#39;mutex_unlock(&amp;trace_types_lock)&amp;#39; in s_start(),<br /> and executing the following script:<br /> <br /> $ echo function_graph &gt; current_tracer<br /> $ cat trace &gt; /dev/null &amp;<br /> $ sleep 5 # Ensure the &amp;#39;cat&amp;#39; reaches the &amp;#39;mdelay(10)&amp;#39; point<br /> $ echo timerlat &gt; current_tracer<br /> <br /> The root cause lies in the two calls to print_graph_function_flags<br /> within print_trace_line during each s_show():<br /> <br /> * One through &amp;#39;iter-&gt;trace-&gt;print_line()&amp;#39;;<br /> * Another through &amp;#39;event-&gt;funcs-&gt;trace()&amp;#39;, which is hidden in<br /> print_trace_fmt() before print_trace_line returns.<br /> <br /> Tracer switching only updates the former, while the latter continues<br /> to use the print_line function of the old tracer, which in the script<br /> above is print_graph_function_flags.<br /> <br /> Moreover, when switching from the &amp;#39;function_graph&amp;#39; tracer to the<br /> &amp;#39;timerlat&amp;#39; tracer, s_start only calls graph_trace_close of the<br /> &amp;#39;function_graph&amp;#39; tracer to free &amp;#39;iter-&gt;private&amp;#39;, but does not set<br /> it to NULL. This provides an opportunity for &amp;#39;event-&gt;funcs-&gt;trace()&amp;#39;<br /> to use an invalid &amp;#39;iter-&gt;private&amp;#39;.<br /> <br /> To fix this issue, set &amp;#39;iter-&gt;private&amp;#39; to NULL immediately after<br /> freeing it in graph_trace_close(), ensuring that an invalid pointer<br /> is not passed to other tracers. Additionally, clean up the unnecessary<br /> &amp;#39;iter-&gt;private = NULL&amp;#39; during each &amp;#39;cat trace&amp;#39; when using wakeup and<br /> irqsoff tracers.<br /> <br /> [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: validate zero num_subauth before sub_auth is accessed<br /> <br /> Access psid-&gt;sub_auth[psid-&gt;num_subauth - 1] without checking<br /> if num_subauth is non-zero leads to an out-of-bounds read.<br /> This patch adds a validation step to ensure num_subauth != 0<br /> before sub_auth is accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in ksmbd_sessions_deregister()<br /> <br /> In multichannel mode, UAF issue can occur in session_deregister<br /> when the second channel sets up a session through the connection of<br /> the first channel. session that is freed through the global session<br /> table can be accessed again through -&gt;sessions of connection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix session use-after-free in multichannel connection<br /> <br /> There is a race condition between session setup and<br /> ksmbd_sessions_deregister. The session can be freed before the connection<br /> is added to channel list of session.<br /> This patch check reference count of session before freeing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vimc: skip .s_stream() for stopped entities<br /> <br /> Syzbot reported [1] a warning prompted by a check in call_s_stream()<br /> that checks whether .s_stream() operation is warranted for unstarted<br /> or stopped subdevs.<br /> <br /> Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that<br /> entities skip a call to .s_stream() unless they have been previously<br /> properly started.<br /> <br /> [1] Syzbot report:<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0<br /> ...<br /> Call Trace:<br /> <br /> vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62<br /> vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline]<br /> vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203<br /> vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256<br /> vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789<br /> vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348<br /> vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline]<br /> vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118<br /> __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122<br /> video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463<br /> v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl fs/ioctl.c:892 [inline]<br /> __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f2b85c01b19<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()<br /> <br /> Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding<br /> the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock<br /> (through crypto_exit_scomp_ops_async()).<br /> <br /> On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through<br /> crypto_scomp_init_tfm()), and then allocates memory. If the allocation<br /> results in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.<br /> <br /> The above dependencies can cause an ABBA deadlock. For example in the<br /> following scenario:<br /> <br /> (1) Task A running on CPU #1:<br /> crypto_alloc_acomp_node()<br /> Holds scomp_lock<br /> Enters reclaim<br /> Reads per_cpu_ptr(pool-&gt;acomp_ctx, 1)<br /> <br /> (2) Task A is descheduled<br /> <br /> (3) CPU #1 goes offline<br /> zswap_cpu_comp_dead(CPU #1)<br /> Holds per_cpu_ptr(pool-&gt;acomp_ctx, 1))<br /> Calls crypto_free_acomp()<br /> Waits for scomp_lock<br /> <br /> (4) Task A running on CPU #2:<br /> Waits for per_cpu_ptr(pool-&gt;acomp_ctx, 1) // Read on CPU #1<br /> DEADLOCK<br /> <br /> Since there is no requirement to call crypto_free_acomp() with the per-CPU<br /> acomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is<br /> unlocked. Also move the acomp_request_free() and kfree() calls for<br /> consistency and to avoid any potential sublte locking dependencies in the<br /> future.<br /> <br /> With this, only setting acomp_ctx fields to NULL occurs with the mutex<br /> held. This is similar to how zswap_cpu_comp_prepare() only initializes<br /> acomp_ctx fields with the mutex held, after performing all allocations<br /> before holding the mutex.<br /> <br /> Opportunistically, move the NULL check on acomp_ctx so that it takes place<br /> before the mutex dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix management of listener transports<br /> <br /> Currently, when no active threads are running, a root user using nfsdctl<br /> command can try to remove a particular listener from the list of previously<br /> added ones, then start the server by increasing the number of threads,<br /> it leads to the following problem:<br /> <br /> [ 158.835354] refcount_t: addition on 0; use-after-free.<br /> [ 158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcount_warn_saturate+0x160/0x1a0<br /> [ 158.836017] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace overlay isofs uinput snd_seq_dummy snd_hrtimer nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables qrtr sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common snd_hda_codec_generic mc e1000e snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore sg loop dm_multipath dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs libcrc32c crct10dif_ce ghash_ce vmwgfx sha2_ce sha256_arm64 sr_mod sha1_ce cdrom nvme drm_client_lib drm_ttm_helper ttm nvme_core drm_kms_helper nvme_auth drm fuse<br /> [ 158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G B W 6.13.0-rc6+ #7<br /> [ 158.840624] Tainted: [B]=BAD_PAGE, [W]=WARN<br /> [ 158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024<br /> [ 158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 158.841563] pc : refcount_warn_saturate+0x160/0x1a0<br /> [ 158.841780] lr : refcount_warn_saturate+0x160/0x1a0<br /> [ 158.842000] sp : ffff800089be7d80<br /> [ 158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148<br /> [ 158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010<br /> [ 158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028<br /> [ 158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000<br /> [ 158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493<br /> [ 158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000<br /> [ 158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001<br /> [ 158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc<br /> [ 158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000<br /> [ 158.845528] Call trace:<br /> [ 158.845658] refcount_warn_saturate+0x160/0x1a0 (P)<br /> [ 158.845894] svc_recv+0x58c/0x680 [sunrpc]<br /> [ 158.846183] nfsd+0x1fc/0x348 [nfsd]<br /> [ 158.846390] kthread+0x274/0x2f8<br /> [ 158.846546] ret_from_fork+0x10/0x20<br /> [ 158.846714] ---[ end trace 0000000000000000 ]---<br /> <br /> nfsd_nl_listener_set_doit() would manipulate the list of transports of<br /> server&amp;#39;s sv_permsocks and close the specified listener but the other<br /> list of transports (server&amp;#39;s sp_xprts list) would not be changed leading<br /> to the problem above.<br /> <br /> Instead, determined if the nfsdctl is trying to remove a listener, in<br /> which case, delete all the existing listener transports and re-create<br /> all-but-the-removed ones.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/bwctrl: Fix NULL pointer dereference on bus number exhaustion<br /> <br /> When BIOS neglects to assign bus numbers to PCI bridges, the kernel<br /> attempts to correct that during PCI device enumeration. If it runs out<br /> of bus numbers, no pci_bus is allocated and the "subordinate" pointer in<br /> the bridge&amp;#39;s pci_dev remains NULL.<br /> <br /> The PCIe bandwidth controller erroneously does not check for a NULL<br /> subordinate pointer and dereferences it on probe.<br /> <br /> Bandwidth control of unusable devices below the bridge is of questionable<br /> utility, so simply error out instead. This mirrors what PCIe hotplug does<br /> since commit 62e4492c3063 ("PCI: Prevent NULL dereference during pciehp<br /> probe").<br /> <br /> The PCI core emits a message with KERN_INFO severity if it has run out of<br /> bus numbers. PCIe hotplug emits an additional message with KERN_ERR<br /> severity to inform the user that hotplug functionality is disabled at the<br /> bridge. A similar message for bandwidth control does not seem merited,<br /> given that its only purpose so far is to expose an up-to-date link speed<br /> in sysfs and throttle the link speed on certain laptops with limited<br /> Thermal Design Power. So error out silently.<br /> <br /> User-visible messages:<br /> <br /> pci 0000:16:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring<br /> [...]<br /> pci_bus 0000:45: busn_res: [bus 45-74] end is updated to 74<br /> pci 0000:16:02.0: devices behind bridge are unusable because [bus 45-74] cannot be assigned for them<br /> [...]<br /> pcieport 0000:16:02.0: pciehp: Hotplug bridge without secondary bus, ignoring<br /> [...]<br /> BUG: kernel NULL pointer dereference<br /> RIP: pcie_update_link_speed<br /> pcie_bwnotif_enable<br /> pcie_bwnotif_probe<br /> pcie_port_probe_service<br /> really_probe

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix kernel panic due to null pointer dereference<br /> <br /> Address a kernel panic caused by a null pointer dereference in the<br /> `mt792x_rx_get_wcid` function. The issue arises because the `deflink` structure<br /> is not properly initialized with the `sta` context. This patch ensures that the<br /> `deflink` structure is correctly linked to the `sta` context, preventing the<br /> null pointer dereference.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000400<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 UID: 0 PID: 470 Comm: mt76-usb-rx phy Not tainted 6.12.13-gentoo-dist #1<br /> Hardware name: /AMD HUDSON-M1, BIOS 4.6.4 11/15/2011<br /> RIP: 0010:mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib]<br /> RSP: 0018:ffffa147c055fd98 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ffff8e9ecb652000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e9ecb652000<br /> RBP: 0000000000000685 R08: ffff8e9ec6570000 R09: 0000000000000000<br /> R10: ffff8e9ecd2ca000 R11: ffff8e9f22a217c0 R12: 0000000038010119<br /> R13: 0000000080843801 R14: ffff8e9ec6570000 R15: ffff8e9ecb652000<br /> FS: 0000000000000000(0000) GS:ffff8e9f22a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000400 CR3: 000000000d2ea000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? page_fault_oops+0x15a/0x2f0<br /> ? search_module_extables+0x19/0x60<br /> ? search_bpf_extables+0x5f/0x80<br /> ? exc_page_fault+0x7e/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? mt792x_rx_get_wcid+0x48/0x140 [mt792x_lib]<br /> mt7921_queue_rx_skb+0x1c6/0xaa0 [mt7921_common]<br /> mt76u_alloc_queues+0x784/0x810 [mt76_usb]<br /> ? __pfx___mt76_worker_fn+0x10/0x10 [mt76]<br /> __mt76_worker_fn+0x4f/0x80 [mt76]<br /> kthread+0xd2/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> ---[ end trace 0000000000000000 ]---