Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: hdmi: Unregister codec device on unbind<br /> <br /> On bind we will register the HDMI codec device but we don&amp;#39;t unregister<br /> it on unbind, leading to a device leakage. Unregister our device at<br /> unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: arc_emac: Fix use after free in arc_mdio_probe()<br /> <br /> If bus-&gt;state is equal to MDIOBUS_ALLOCATED, mdiobus_free(bus) will free<br /> the "bus". But bus-&gt;name is still used in the next line, which will lead<br /> to a use after free.<br /> <br /> We can fix it by putting the name in a local variable and make the<br /> bus-&gt;name point to the rodata section "name",then use the name in the<br /> error message without referring to bus to avoid the uaf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix kernel-infoleak for SCTP sockets<br /> <br /> syzbot reported a kernel infoleak [1] of 4 bytes.<br /> <br /> After analysis, it turned out r-&gt;idiag_expires is not initialized<br /> if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()<br /> <br /> Make sure to clear idiag_timer/idiag_retrans/idiag_expires<br /> and let inet_diag_msg_sctpasoc_fill() fill them again if needed.<br /> <br /> [1]<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668<br /> instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> copyout lib/iov_iter.c:154 [inline]<br /> _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668<br /> copy_to_iter include/linux/uio.h:162 [inline]<br /> simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519<br /> __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425<br /> skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533<br /> skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]<br /> netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977<br /> sock_recvmsg_nosec net/socket.c:948 [inline]<br /> sock_recvmsg net/socket.c:966 [inline]<br /> __sys_recvfrom+0x795/0xa10 net/socket.c:2097<br /> __do_sys_recvfrom net/socket.c:2115 [inline]<br /> __se_sys_recvfrom net/socket.c:2111 [inline]<br /> __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:737 [inline]<br /> slab_alloc_node mm/slub.c:3247 [inline]<br /> __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975<br /> kmalloc_reserve net/core/skbuff.c:354 [inline]<br /> __alloc_skb+0x545/0xf90 net/core/skbuff.c:426<br /> alloc_skb include/linux/skbuff.h:1158 [inline]<br /> netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248<br /> __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373<br /> netlink_dump_start include/linux/netlink.h:254 [inline]<br /> inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341<br /> sock_diag_rcv_msg+0x24a/0x620<br /> netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494<br /> sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]<br /> netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343<br /> netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919<br /> sock_sendmsg_nosec net/socket.c:705 [inline]<br /> sock_sendmsg net/socket.c:725 [inline]<br /> sock_write_iter+0x594/0x690 net/socket.c:1061<br /> do_iter_readv_writev+0xa7f/0xc70<br /> do_iter_write+0x52c/0x1500 fs/read_write.c:851<br /> vfs_writev fs/read_write.c:924 [inline]<br /> do_writev+0x645/0xe00 fs/read_write.c:967<br /> __do_sys_writev fs/read_write.c:1040 [inline]<br /> __se_sys_writev fs/read_write.c:1037 [inline]<br /> __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Bytes 68-71 of 2508 are uninitialized<br /> Memory access of size 2508 starts at ffff888114f9b000<br /> Data copied to user address 00007f7fe09ff2e0<br /> <br /> CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gianfar: ethtool: Fix refcount leak in gfar_get_ts_info<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, We should use of_node_put() on it when done<br /> Add the missing of_node_put() to release the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: port100: fix use-after-free in port100_send_complete<br /> <br /> Syzbot reported UAF in port100_send_complete(). The root case is in<br /> missing usb_kill_urb() calls on error handling path of -&gt;probe function.<br /> <br /> port100_send_complete() accesses devm allocated memory which will be<br /> freed on probe failure. We should kill this urbs before returning an<br /> error from probe function to prevent reported use-after-free<br /> <br /> Fail log:<br /> <br /> BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935<br /> Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26<br /> ...<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255<br /> __kasan_report mm/kasan/report.c:442 [inline]<br /> kasan_report.cold+0x83/0xdf mm/kasan/report.c:459<br /> port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935<br /> __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670<br /> <br /> ...<br /> <br /> Allocated by task 1255:<br /> kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38<br /> kasan_set_track mm/kasan/common.c:45 [inline]<br /> set_alloc_info mm/kasan/common.c:436 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:515 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:474 [inline]<br /> __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524<br /> alloc_dr drivers/base/devres.c:116 [inline]<br /> devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823<br /> devm_kzalloc include/linux/device.h:209 [inline]<br /> port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502<br /> <br /> Freed by task 1255:<br /> kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38<br /> kasan_set_track+0x21/0x30 mm/kasan/common.c:45<br /> kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370<br /> ____kasan_slab_free mm/kasan/common.c:366 [inline]<br /> ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328<br /> kasan_slab_free include/linux/kasan.h:236 [inline]<br /> __cache_free mm/slab.c:3437 [inline]<br /> kfree+0xf8/0x2b0 mm/slab.c:3794<br /> release_nodes+0x112/0x1a0 drivers/base/devres.c:501<br /> devres_release_all+0x114/0x190 drivers/base/devres.c:530<br /> really_probe+0x626/0xcc0 drivers/base/dd.c:670

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix a race on command flush flow<br /> <br /> Fix a refcount use after free warning due to a race on command entry.<br /> Such race occurs when one of the commands releases its last refcount and<br /> frees its index and entry while another process running command flush<br /> flow takes refcount to this command entry. The process which handles<br /> commands flush may see this command as needed to be flushed if the other<br /> process released its refcount but didn&amp;#39;t release the index yet. Fix it<br /> by adding the needed spin lock.<br /> <br /> It fixes the following warning trace:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0<br /> ...<br /> RIP: 0010:refcount_warn_saturate+0x80/0xe0<br /> ...<br /> Call Trace:<br /> <br /> mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core]<br /> mlx5_cmd_flush+0x3a/0xf0 [mlx5_core]<br /> enter_error_state+0x44/0x80 [mlx5_core]<br /> mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core]<br /> process_one_work+0x1be/0x390<br /> worker_thread+0x4d/0x3d0<br /> ? rescuer_thread+0x350/0x350<br /> kthread+0x141/0x160<br /> ? set_kthread_struct+0x40/0x40<br /> ret_from_fork+0x1f/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr<br /> <br /> This node pointer is returned by of_find_compatible_node() with<br /> refcount incremented. Calling of_node_put() to aovid the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethernet: Fix error handling in xemaclite_of_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with refcount<br /> incremented in this function. Calling of_node_put() to avoid the<br /> refcount leak. As the remove function do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> swiotlb: fix info leak with DMA_FROM_DEVICE<br /> <br /> The problem I&amp;#39;m addressing was discovered by the LTP test covering<br /> cve-2018-1000204.<br /> <br /> A short description of what happens follows:<br /> 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO<br /> interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV<br /> and a corresponding dxferp. The peculiar thing about this is that TUR<br /> is not reading from the device.<br /> 2) In sg_start_req() the invocation of blk_rq_map_user() effectively<br /> bounces the user-space buffer. As if the device was to transfer into<br /> it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in<br /> sg_build_indirect()") we make sure this first bounce buffer is<br /> allocated with GFP_ZERO.<br /> 3) For the rest of the story we keep ignoring that we have a TUR, so the<br /> device won&amp;#39;t touch the buffer we prepare as if the we had a<br /> DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device<br /> and the buffer allocated by SG is mapped by the function<br /> virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here<br /> scatter-gather and not scsi generics). This mapping involves bouncing<br /> via the swiotlb (we need swiotlb to do virtio in protected guest like<br /> s390 Secure Execution, or AMD SEV).<br /> 4) When the SCSI TUR is done, we first copy back the content of the second<br /> (that is swiotlb) bounce buffer (which most likely contains some<br /> previous IO data), to the first bounce buffer, which contains all<br /> zeros. Then we copy back the content of the first bounce buffer to<br /> the user-space buffer.<br /> 5) The test case detects that the buffer, which it zero-initialized,<br /> ain&amp;#39;t all zeros and fails.<br /> <br /> One can argue that this is an swiotlb problem, because without swiotlb<br /> we leak all zeros, and the swiotlb should be transparent in a sense that<br /> it does not affect the outcome (if all other participants are well<br /> behaved).<br /> <br /> Copying the content of the original buffer into the swiotlb buffer is<br /> the only way I can think of to make swiotlb transparent in such<br /> scenarios. So let&amp;#39;s do just that if in doubt, but allow the driver<br /> to tell us that the whole mapped buffer is going to be overwritten,<br /> in which case we can preserve the old behavior and avoid the performance<br /> impact of the extra bounce.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Page fault in reply q processing<br /> <br /> A page fault was encountered in mpt3sas on a LUN reset error path:<br /> <br /> [ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30) tr_method(0x0) smid(3) msix_index(0)<br /> [ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2)<br /> [ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29a2)<br /> [ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 ff fc 00<br /> [ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b0000272b9), phy(0)<br /> [ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), slot(0)<br /> [ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of smid(0), task_type(0x05), handle(0x0002)<br /> [ 149.875202] BUG: unable to handle page fault for address: 00000007fffc445d<br /> [ 149.885617] #PF: supervisor read access in kernel mode<br /> [ 149.894346] #PF: error_code(0x0000) - not-present page<br /> [ 149.903123] PGD 0 P4D 0<br /> [ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S O 5.10.89-altav-1 #1<br /> [ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB , BIOS ATHG2.2.02.01 09/10/2021<br /> [ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas]<br /> [ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee<br /> [ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246<br /> [ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 000000002548f071<br /> [ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125ed50d8<br /> [ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffff7fff<br /> [ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 0000000000000000<br /> [ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034cdea80<br /> [ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:0000000000000000<br /> [ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 0000000000770ee0<br /> [ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 150.108323] PKRU: 55555554<br /> [ 150.114690] Call Trace:<br /> [ 150.120497] ? printk+0x48/0x4a<br /> [ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas]<br /> [ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas]<br /> [ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas]<br /> [ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod]<br /> [ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod]<br /> [ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]<br /> [ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60<br /> [ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]<br /> [ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod]<br /> [ 150.203206] ? __schedule+0x1e9/0x610<br /> [ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod]<br /> [ 150.217924] kthread+0x12e/0x150<br /> [ 150.224041] ? kthread_worker_fn+0x130/0x130<br /> [ 150.231206] ret_from_fork+0x1f/0x30<br /> <br /> This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q<br /> pointer outside of the list_for_each_entry() loop. At the end of the full<br /> list traversal the pointer is invalid.<br /> <br /> Move the _base_process_reply_queue() call inside of the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: aiptek - properly check endpoint type<br /> <br /> Syzbot reported warning in usb_submit_urb() which is caused by wrong<br /> endpoint type. There was a check for the number of endpoints, but not<br /> for the type of endpoint.<br /> <br /> Fix it by replacing old desc.bNumEndpoints check with<br /> usb_find_common_endpoints() helper for finding endpoints<br /> <br /> Fail log:<br /> <br /> usb 5-1: BOGUS urb xfer, pipe 1 != type 3<br /> WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> Modules linked in:<br /> CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> ...<br /> Call Trace:<br /> <br /> aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830<br /> input_open_device+0x1bb/0x320 drivers/input/input.c:629<br /> kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: rndis: prevent integer overflow in rndis_set_response()<br /> <br /> If "BufOffset" is very large the "BufOffset + 8" operation can have an<br /> integer overflow.