Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: do not leave a dangling sk pointer in __smc_create()<br /> <br /> Thanks to commit 4bbd360a5084 ("socket: Print pf-&gt;create() when<br /> it does not clear sock-&gt;sk on failure."), syzbot found an issue with AF_SMC:<br /> <br /> smc_create must clear sock-&gt;sk on failure, family: 43, type: 1, protocol: 0<br /> WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563<br /> Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7<br /> RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246<br /> RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50<br /> R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8<br /> R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0<br /> FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sock_create net/socket.c:1616 [inline]<br /> __sys_socket_create net/socket.c:1653 [inline]<br /> __sys_socket+0x150/0x3c0 net/socket.c:1700<br /> __do_sys_socket net/socket.c:1714 [inline]<br /> __se_sys_socket net/socket.c:1712 [inline]<br /> <br /> For reference, see commit 2d859aff775d ("Merge branch<br /> &amp;#39;do-not-leave-dangling-sk-pointers-in-pf-create-functions&amp;#39;")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix missing locking causing hanging calls<br /> <br /> If a call gets aborted (e.g. because kafs saw a signal) between it being<br /> queued for connection and the I/O thread picking up the call, the abort<br /> will be prioritised over the connection and it will be removed from<br /> local-&gt;new_client_calls by rxrpc_disconnect_client_call() without a lock<br /> being held. This may cause other calls on the list to disappear if a race<br /> occurs.<br /> <br /> Fix this by taking the client_call_lock when removing a call from whatever<br /> list its -&gt;wait_link happens to be on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts<br /> <br /> Enqueue packets in dql after dma engine starts causes race condition.<br /> Tx transfer starts once dma engine is started and may execute dql dequeue<br /> in completion before it gets queued. It results in following kernel crash<br /> while running iperf stress test:<br /> <br /> kernel BUG at lib/dynamic_queue_limits.c:99!<br /> <br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> pc : dql_completed+0x238/0x248<br /> lr : dql_completed+0x3c/0x248<br /> <br /> Call trace:<br /> dql_completed+0x238/0x248<br /> axienet_dma_tx_cb+0xa0/0x170<br /> xilinx_dma_do_tasklet+0xdc/0x290<br /> tasklet_action_common+0xf8/0x11c<br /> tasklet_action+0x30/0x3c<br /> handle_softirqs+0xf8/0x230<br /> <br /> <br /> Start dmaengine after enqueue in dql fixes the crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx24116: prevent overflows on SNR calculus<br /> <br /> as reported by Coverity, if reading SNR registers fail, a negative<br /> number will be returned, causing an underflow when reading SNR<br /> registers.<br /> <br /> Prevent that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove<br /> <br /> In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not<br /> null. So the release of the dma channel leads to the following issue:<br /> [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller:<br /> dma_request_slave_channel error -19<br /> [ 4.888975] Unable to handle kernel NULL pointer dereference<br /> at virtual address 000000000000003d<br /> [...]<br /> [ 5.096577] Call trace:<br /> [ 5.099099] dma_release_channel+0x24/0x100<br /> [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx]<br /> [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx]<br /> <br /> To avoid this issue, release channel only if the pointer is valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: arc: fix the device for dma_map_single/dma_unmap_single<br /> <br /> The ndev-&gt;dev and pdev-&gt;dev aren&amp;#39;t the same device, use ndev-&gt;dev.parent<br /> which has dma_mask, ndev-&gt;dev.parent is just pdev-&gt;dev.<br /> Or it would cause the following issue:<br /> <br /> [ 39.933526] ------------[ cut here ]------------<br /> [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix kernel crash when uninstalling driver<br /> <br /> When the driver is uninstalled and the VF is disabled concurrently, a<br /> kernel crash occurs. The reason is that the two actions call function<br /> pci_disable_sriov(). The num_VFs is checked to determine whether to<br /> release the corresponding resources. During the second calling, num_VFs<br /> is not 0 and the resource release function is called. However, the<br /> corresponding resource has been released during the first invoking.<br /> Therefore, the problem occurs:<br /> <br /> [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> ...<br /> [15278.131557][T50670] Call trace:<br /> [15278.134686][T50670] klist_put+0x28/0x12c<br /> [15278.138682][T50670] klist_del+0x14/0x20<br /> [15278.142592][T50670] device_del+0xbc/0x3c0<br /> [15278.146676][T50670] pci_remove_bus_device+0x84/0x120<br /> [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80<br /> [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c<br /> [15278.162485][T50670] sriov_disable+0x50/0x11c<br /> [15278.166829][T50670] pci_disable_sriov+0x24/0x30<br /> [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]<br /> [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge]<br /> [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230<br /> [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30<br /> [15278.193848][T50670] invoke_syscall+0x50/0x11c<br /> [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164<br /> [15278.203837][T50670] do_el0_svc+0x34/0xcc<br /> [15278.207834][T50670] el0_svc+0x20/0x30<br /> <br /> For details, see the following figure.<br /> <br /> rmmod hclge disable VFs<br /> ----------------------------------------------------<br /> hclge_exit() sriov_numvfs_store()<br /> ... device_lock()<br /> pci_disable_sriov() hns3_pci_sriov_configure()<br /> pci_disable_sriov()<br /> sriov_disable()<br /> sriov_disable() if !num_VFs :<br /> if !num_VFs : return;<br /> return; sriov_del_vfs()<br /> sriov_del_vfs() ...<br /> ... klist_put()<br /> klist_put() ...<br /> ... num_VFs = 0;<br /> num_VFs = 0; device_unlock();<br /> <br /> In this patch, when driver is removing, we get the device_lock()<br /> to protect num_VFs, just like sriov_numvfs_store().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: allocate vf_state during PF probes<br /> <br /> In the previous implementation, vf_state is allocated memory only when VF<br /> is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before<br /> VF is enabled to configure the MAC address of VF. If this is the case,<br /> enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null<br /> pointer. The simplified error log is as follows.<br /> <br /> root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89<br /> [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004<br /> [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy<br /> [ 173.641973] lr : do_setlink+0x4a8/0xec8<br /> [ 173.732292] Call trace:<br /> [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80<br /> [ 173.738847] __rtnl_newlink+0x530/0x89c<br /> [ 173.742692] rtnl_newlink+0x50/0x7c<br /> [ 173.746189] rtnetlink_rcv_msg+0x128/0x390<br /> [ 173.750298] netlink_rcv_skb+0x60/0x130<br /> [ 173.754145] rtnetlink_rcv+0x18/0x24<br /> [ 173.757731] netlink_unicast+0x318/0x380<br /> [ 173.761665] netlink_sendmsg+0x17c/0x3c8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: fix a crash if blk_alloc_disk fails<br /> <br /> If blk_alloc_disk fails, the variable md-&gt;disk is set to an error value.<br /> cleanup_mapped_device will see that md-&gt;disk is non-NULL and it will<br /> attempt to access it, causing a crash on this statement<br /> "md-&gt;disk-&gt;private_data = NULL;".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation<br /> <br /> When sealing or unsealing a key blob we currently do not wait for<br /> the AEAD cipher operation to finish and simply return after submitting<br /> the request. If there is some load on the system we can exit before<br /> the cipher operation is done and the buffer we read from/write to<br /> is already removed from the stack. This will e.g. result in NULL<br /> pointer dereference errors in the DCP driver during blob creation.<br /> <br /> Fix this by waiting for the AEAD cipher operation to finish before<br /> resuming the seal and unseal calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: check outstanding simultaneous SMB operations<br /> <br /> If Client send simultaneous SMB operations to ksmbd, It exhausts too much<br /> memory through the "ksmbd_work_cache”. It will cause OOM issue.<br /> ksmbd has a credit mechanism but it can&amp;#39;t handle this problem. This patch<br /> add the check if it exceeds max credits to prevent this problem by assuming<br /> that one smb request consumes at least one credit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: fix potential out-of-bounds access on the first resume<br /> <br /> Out-of-bounds access occurs if the fast device is expanded unexpectedly<br /> before the first-time resume of the cache table. This happens because<br /> expanding the fast device requires reloading the cache table for<br /> cache_create to allocate new in-core data structures that fit the new<br /> size, and the check in cache_preresume is not performed during the<br /> first resume, leading to the issue.<br /> <br /> Reproduce steps:<br /> <br /> 1. prepare component devices:<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc 262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct<br /> <br /> 2. load a cache table of 512 cache blocks, and deliberately expand the<br /> fast device before resuming the cache, making the in-core data<br /> structures inadequate.<br /> <br /> dmsetup create cache --notable<br /> dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"<br /> dmsetup resume cdata<br /> dmsetup resume cache<br /> <br /> 3. suspend the cache to write out the in-core dirty bitset and hint<br /> array, leading to out-of-bounds access to the dirty bitset at offset<br /> 0x40:<br /> <br /> dmsetup suspend cache<br /> <br /> KASAN reports:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80<br /> Read of size 8 at addr ffffc90000085040 by task dmsetup/90<br /> <br /> (...snip...)<br /> The buggy address belongs to the virtual mapping at<br /> [ffffc90000085000, ffffc90000087000) created by:<br /> cache_ctr+0x176a/0x35f0<br /> <br /> (...snip...)<br /> Memory state around the buggy address:<br /> ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> <br /> Fix by checking the size change on the first resume.