Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> security/keys: fix slab-out-of-bounds in key_task_permission<br /> <br /> KASAN reports an out of bounds read:<br /> BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36<br /> BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]<br /> BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410<br /> security/keys/permission.c:54<br /> Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362<br /> <br /> CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:82 [inline]<br /> dump_stack+0x107/0x167 lib/dump_stack.c:123<br /> print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400<br /> __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560<br /> kasan_report+0x3a/0x50 mm/kasan/report.c:585<br /> __kuid_val include/linux/uidgid.h:36 [inline]<br /> uid_eq include/linux/uidgid.h:63 [inline]<br /> key_task_permission+0x394/0x410 security/keys/permission.c:54<br /> search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793<br /> <br /> This issue was also reported by syzbot.<br /> <br /> It can be reproduced by following these steps(more details [1]):<br /> 1. Obtain more than 32 inputs that have similar hashes, which ends with the<br /> pattern &amp;#39;0xxxxxxxe6&amp;#39;.<br /> 2. Reboot and add the keys obtained in step 1.<br /> <br /> The reproducer demonstrates how this issue happened:<br /> 1. In the search_nested_keyrings function, when it iterates through the<br /> slots in a node(below tag ascend_to_node), if the slot pointer is meta<br /> and node-&gt;back_pointer != NULL(it means a root), it will proceed to<br /> descend_to_node. However, there is an exception. If node is the root,<br /> and one of the slots points to a shortcut, it will be treated as a<br /> keyring.<br /> 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.<br /> However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as<br /> ASSOC_ARRAY_PTR_SUBTYPE_MASK.<br /> 3. When 32 keys with the similar hashes are added to the tree, the ROOT<br /> has keys with hashes that are not similar (e.g. slot 0) and it splits<br /> NODE A without using a shortcut. When NODE A is filled with keys that<br /> all hashes are xxe6, the keys are similar, NODE A will split with a<br /> shortcut. Finally, it forms the tree as shown below, where slot 6 points<br /> to a shortcut.<br /> <br /> NODE A<br /> +------&gt;+---+<br /> ROOT | | 0 | xxe6<br /> +---+ | +---+<br /> xxxx | 0 | shortcut : : xxe6<br /> +---+ | +---+<br /> xxe6 : : | | | xxe6<br /> +---+ | +---+<br /> | 6 |---+ : : xxe6<br /> +---+ +---+<br /> xxe6 : : | f | xxe6<br /> +---+ +---+<br /> xxe6 | f |<br /> +---+<br /> <br /> 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,<br /> it may be mistakenly transferred to a key*, leading to a read<br /> out-of-bounds read.<br /> <br /> To fix this issue, one should jump to descend_to_node if the ptr is a<br /> shortcut, regardless of whether the node is root or not.<br /> <br /> [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/<br /> <br /> [jarkko: tweaked the commit message a bit to have an appropriate closes<br /> tag.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: zero-initialize the report buffer<br /> <br /> Since the report buffer is used by all kinds of drivers in various ways, let&amp;#39;s<br /> zero-initialize it during allocation to make sure that it can&amp;#39;t be ever used<br /> to leak kernel memory via specially-crafted report.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: vivid: fix buffer overwrite when using &gt; 32 buffers<br /> <br /> The maximum number of buffers that can be requested was increased to<br /> 64 for the video capture queue. But video capture used a must_blank<br /> array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an<br /> out-of-bounds write when using buffer indices &gt;= 32.<br /> <br /> Create a new define MAX_VID_CAP_BUFFERS that is used to access the<br /> must_blank array and set max_num_buffers for the video capture queue.<br /> <br /> This solves a crash reported by:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=219258

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: av7110: fix a spectre vulnerability<br /> <br /> As warned by smatch:<br /> drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue &amp;#39;av7110-&gt;ci_slot&amp;#39; [w] (local cap)<br /> <br /> There is a spectre-related vulnerability at the code. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-core: add missing buffer index check<br /> <br /> dvb_vb2_expbuf() didn&amp;#39;t check if the given buffer index was<br /> for a valid buffer. Add this check.

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 /> 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 /> 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