Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ptdma: check for null desc before calling pt_cmd_callback<br /> <br /> Resolves a panic that can occur on AMD systems, typically during host<br /> shutdown, after the PTDMA driver had been exercised. The issue was<br /> the pt_issue_pending() function is mistakenly assuming that there will<br /> be at least one descriptor in the Submitted queue when the function<br /> is called. However, it is possible that both the Submitted and Issued<br /> queues could be empty, which could result in pt_cmd_callback() being<br /> mistakenly called with a NULL pointer.<br /> Ref: Bugzilla Bug 216856.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Fix crash due to uninitialized current_vmcs<br /> <br /> KVM enables &amp;#39;Enlightened VMCS&amp;#39; and &amp;#39;Enlightened MSR Bitmap&amp;#39; when running as<br /> a nested hypervisor on top of Hyper-V. When MSR bitmap is updated,<br /> evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to mark<br /> that the msr bitmap was changed.<br /> <br /> vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr<br /> -&gt; vmx_msr_bitmap_l01_changed which in the end calls this function. The<br /> function checks for current_vmcs if it is null but the check is<br /> insufficient because current_vmcs is not initialized. Because of this, the<br /> code might incorrectly write to the structure pointed by current_vmcs value<br /> left by another task. Preemption is not disabled, the current task can be<br /> preempted and moved to another CPU while current_vmcs is accessed multiple<br /> times from evmcs_touch_msr_bitmap() which leads to crash.<br /> <br /> The manipulation of MSR bitmaps by callers happens only for vmcs01 so the<br /> solution is to use vmx-&gt;vmcs01.vmcs instead of current_vmcs.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000338<br /> PGD 4e1775067 P4D 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> ...<br /> RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel]<br /> ...<br /> Call Trace:<br /> vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel]<br /> vmx_vcpu_create+0xe6/0x540 [kvm_intel]<br /> kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm]<br /> kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm]<br /> kvm_vm_ioctl+0x53f/0x790 [kvm]<br /> __x64_sys_ioctl+0x8a/0xc0<br /> do_syscall_64+0x5c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: atmel-quadspi: Free resources even if runtime resume failed in .remove()<br /> <br /> An early error exit in atmel_qspi_remove() doesn&amp;#39;t prevent the device<br /> unbind. So this results in an spi controller with an unbound parent<br /> and unmapped register space (because devm_ioremap_resource() is undone).<br /> So using the remaining spi controller probably results in an oops.<br /> <br /> Instead unregister the controller unconditionally and only skip hardware<br /> access and clk disable.<br /> <br /> Also add a warning about resume failing and return zero unconditionally.<br /> The latter has the only effect to suppress a less helpful error message by<br /> the spi core.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hidraw: fix data race on device refcount<br /> <br /> The hidraw_open() function increments the hidraw device reference<br /> counter. The counter has no dedicated synchronization mechanism,<br /> resulting in a potential data race when concurrently opening a device.<br /> <br /> The race is a regression introduced by commit 8590222e4b02 ("HID:<br /> hidraw: Replace hidraw device table mutex with a rwsem"). While<br /> minors_rwsem is intended to protect the hidraw_table itself, by instead<br /> acquiring the lock for writing, the reference counter is also protected.<br /> This is symmetrical to hidraw_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: mcq: Fix &amp;hwq-&gt;cq_lock deadlock issue<br /> <br /> When ufshcd_err_handler() is executed, CQ event interrupt can enter waiting<br /> for the same lock. This can happen in ufshcd_handle_mcq_cq_events() and<br /> also in ufs_mtk_mcq_intr(). The following warning message will be generated<br /> when &amp;hwq-&gt;cq_lock is used in IRQ context with IRQ enabled. Use<br /> ufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave instead of spin_lock to<br /> resolve the deadlock issue.<br /> <br /> [name:lockdep&amp;]WARNING: inconsistent lock state<br /> [name:lockdep&amp;]--------------------------------<br /> [name:lockdep&amp;]inconsistent {IN-HARDIRQ-W} -&gt; {HARDIRQ-ON-W} usage.<br /> [name:lockdep&amp;]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffffff8028444600 (&amp;hwq-&gt;cq_lock){?.-.}-{2:2}, at:<br /> ufshcd_mcq_poll_cqe_lock+0x30/0xe0<br /> [name:lockdep&amp;]{IN-HARDIRQ-W} state was registered at:<br /> lock_acquire+0x17c/0x33c<br /> _raw_spin_lock+0x5c/0x7c<br /> ufshcd_mcq_poll_cqe_lock+0x30/0xe0<br /> ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod]<br /> __handle_irq_event_percpu+0x140/0x3ec<br /> handle_irq_event+0x50/0xd8<br /> handle_fasteoi_irq+0x148/0x2b0<br /> generic_handle_domain_irq+0x4c/0x6c<br /> gic_handle_irq+0x58/0x134<br /> call_on_irq_stack+0x40/0x74<br /> do_interrupt_handler+0x84/0xe4<br /> el1_interrupt+0x3c/0x78<br /> <br /> <br /> Possible unsafe locking scenario:<br /> CPU0<br /> ----<br /> lock(&amp;hwq-&gt;cq_lock);<br /> <br /> lock(&amp;hwq-&gt;cq_lock);<br /> *** DEADLOCK ***<br /> 2 locks held by kworker/u16:4/260:<br /> <br /> [name:lockdep&amp;]<br /> stack backtrace:<br /> CPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S W OE<br /> 6.1.17-mainline-android14-2-g277223301adb #1<br /> Workqueue: ufs_eh_wq_0 ufshcd_err_handler<br /> <br /> Call trace:<br /> dump_backtrace+0x10c/0x160<br /> show_stack+0x20/0x30<br /> dump_stack_lvl+0x98/0xd8<br /> dump_stack+0x20/0x60<br /> print_usage_bug+0x584/0x76c<br /> mark_lock_irq+0x488/0x510<br /> mark_lock+0x1ec/0x25c<br /> __lock_acquire+0x4d8/0xffc<br /> lock_acquire+0x17c/0x33c<br /> _raw_spin_lock+0x5c/0x7c<br /> ufshcd_mcq_poll_cqe_lock+0x30/0xe0<br /> ufshcd_poll+0x68/0x1b0<br /> ufshcd_transfer_req_compl+0x9c/0xc8<br /> ufshcd_err_handler+0x3bc/0xea0<br /> process_one_work+0x2f4/0x7e8<br /> worker_thread+0x234/0x450<br /> kthread+0x110/0x134<br /> ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: usbtmc: Fix direction for 0-length ioctl control messages<br /> <br /> The syzbot fuzzer found a problem in the usbtmc driver: When a user<br /> submits an ioctl for a 0-length control transfer, the driver does not<br /> check that the direction is set to OUT:<br /> <br /> ------------[ cut here ]------------<br /> usb 3-1: BOGUS control dir, pipe 80000b80 doesn&amp;#39;t match bRequestType fd<br /> WARNING: CPU: 0 PID: 5100 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411<br /> Modules linked in:<br /> CPU: 0 PID: 5100 Comm: syz-executor428 Not tainted 6.3.0-syzkaller-12049-g58390c8ce1bd #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411<br /> Code: 7c 24 40 e8 1b 13 5c fb 48 8b 7c 24 40 e8 21 1d f0 fe 45 89 e8 44 89 f1 4c 89 e2 48 89 c6 48 c7 c7 e0 b5 fc 8a e8 19 c8 23 fb 0b e9 9f ee ff ff e8 ed 12 5c fb 0f b6 1d 12 8a 3c 08 31 ff 41<br /> RSP: 0018:ffffc90003d2fb00 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff8880789e9058 RCX: 0000000000000000<br /> RDX: ffff888029593b80 RSI: ffffffff814c1447 RDI: 0000000000000001<br /> RBP: ffff88801ea742f8 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff88802915e528<br /> R13: 00000000000000fd R14: 0000000080000b80 R15: ffff8880222b3100<br /> FS: 0000555556ca63c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f9ef4d18150 CR3: 0000000073e5b000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<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 /> usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1954 [inline]<br /> usbtmc_ioctl+0x1b3d/0x2840 drivers/usb/class/usbtmc.c:2097<br /> <br /> To fix this, we must override the direction in the bRequestType field<br /> of the control request structure when the length is 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF<br /> <br /> After a call to console_unlock() in vcs_write() the vc_data struct can be<br /> freed by vc_port_destruct(). Because of that, the struct vc_data pointer<br /> must be reloaded in the while loop in vcs_write() after console_lock() to<br /> avoid a UAF when vcs_size() is called.<br /> <br /> Syzkaller reported a UAF in vcs_size().<br /> <br /> BUG: KASAN: slab-use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)<br /> Read of size 4 at addr ffff8880beab89a8 by task repro_vcs_size/4119<br /> <br /> Call Trace:<br /> <br /> __asan_report_load4_noabort (mm/kasan/report_generic.c:380)<br /> vcs_size (drivers/tty/vt/vc_screen.c:215)<br /> vcs_write (drivers/tty/vt/vc_screen.c:664)<br /> vfs_write (fs/read_write.c:582 fs/read_write.c:564)<br /> ...<br /> <br /> <br /> Allocated by task 1213:<br /> kmalloc_trace (mm/slab_common.c:1064)<br /> vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680<br /> drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058)<br /> con_install (drivers/tty/vt/vt.c:3334)<br /> tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415<br /> drivers/tty/tty_io.c:1392)<br /> tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128)<br /> chrdev_open (fs/char_dev.c:415)<br /> do_dentry_open (fs/open.c:921)<br /> vfs_open (fs/open.c:1052)<br /> ...<br /> <br /> Freed by task 4116:<br /> kfree (mm/slab_common.c:1016)<br /> vc_port_destruct (drivers/tty/vt/vt.c:1044)<br /> tty_port_destructor (drivers/tty/tty_port.c:296)<br /> tty_port_put (drivers/tty/tty_port.c:312)<br /> vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))<br /> vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)<br /> tty_ioctl (drivers/tty/tty_io.c:2778)<br /> ...<br /> <br /> The buggy address belongs to the object at ffff8880beab8800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 424 bytes inside of<br /> freed 1024-byte region [ffff8880beab8800, ffff8880beab8c00)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000afc77580 refcount:1 mapcount:0 mapping:0000000000000000<br /> index:0x0 pfn:0xbeab8<br /> head:00000000afc77580 order:3 entire_mapcount:0 nr_pages_mapped:0<br /> pincount:0<br /> flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)<br /> page_type: 0xffffffff()<br /> raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead000000000002<br /> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt;ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff8880beab8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8880beab8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> Disabling lock debugging due to kernel taint

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setup<br /> <br /> variable *nplanes is provided by user via system call argument. The<br /> possible value of q_data-&gt;fmt-&gt;num_planes is 1-3, while the value<br /> of *nplanes can be 1-8. The array access by index i can cause array<br /> out-of-bounds.<br /> <br /> Fix this bug by checking *nplanes against the array size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: fix clear_user_rep_good() exception handling annotation<br /> <br /> This code no longer exists in mainline, because it was removed in<br /> commit d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory<br /> clearing") upstream.<br /> <br /> However, rather than backport the full range of x86 memory clearing and<br /> copying cleanups, fix the exception table annotation placement for the<br /> final &amp;#39;rep movsb&amp;#39; in clear_user_rep_good(): rather than pointing at the<br /> actual instruction that did the user space access, it pointed to the<br /> register move just before it.<br /> <br /> That made sense from a code flow standpoint, but not from an actual<br /> usage standpoint: it means that if user access takes an exception, the<br /> exception handler won&amp;#39;t actually find the instruction in the exception<br /> tables.<br /> <br /> As a result, rather than fixing it up and returning -EFAULT, it would<br /> then turn it into a kernel oops report instead, something like:<br /> <br /> BUG: unable to handle page fault for address: 0000000020081000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> ...<br /> RIP: 0010:clear_user_rep_good+0x1c/0x30 arch/x86/lib/clear_page_64.S:147<br /> ...<br /> Call Trace:<br /> __clear_user arch/x86/include/asm/uaccess_64.h:103 [inline]<br /> clear_user arch/x86/include/asm/uaccess_64.h:124 [inline]<br /> iov_iter_zero+0x709/0x1290 lib/iov_iter.c:800<br /> iomap_dio_hole_iter fs/iomap/direct-io.c:389 [inline]<br /> iomap_dio_iter fs/iomap/direct-io.c:440 [inline]<br /> __iomap_dio_rw+0xe3d/0x1cd0 fs/iomap/direct-io.c:601<br /> iomap_dio_rw+0x40/0xa0 fs/iomap/direct-io.c:689<br /> ext4_dio_read_iter fs/ext4/file.c:94 [inline]<br /> ext4_file_read_iter+0x4be/0x690 fs/ext4/file.c:145<br /> call_read_iter include/linux/fs.h:2183 [inline]<br /> do_iter_readv_writev+0x2e0/0x3b0 fs/read_write.c:733<br /> do_iter_read+0x2f2/0x750 fs/read_write.c:796<br /> vfs_readv+0xe5/0x150 fs/read_write.c:916<br /> do_preadv+0x1b6/0x270 fs/read_write.c:1008<br /> __do_sys_preadv2 fs/read_write.c:1070 [inline]<br /> __se_sys_preadv2 fs/read_write.c:1061 [inline]<br /> __x64_sys_preadv2+0xef/0x150 fs/read_write.c:1061<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 /> which then looks like a filesystem bug rather than the incorrect<br /> exception annotation that it is.<br /> <br /> [ The alternative to this one-liner fix is to take the upstream series<br /> that cleans this all up:<br /> <br /> 68674f94ffc9 ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory copies")<br /> 20f3337d350c ("x86: don&amp;#39;t use REP_GOOD or ERMS for small memory clearing")<br /> adfcf4231b8c ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory copies")<br /> * d2c95f9d6802 ("x86: don&amp;#39;t use REP_GOOD or ERMS for user memory clearing")<br /> 3639a535587d ("x86: move stac/clac from user copy routines into callers")<br /> 577e6a7fd50d ("x86: inline the &amp;#39;rep movs&amp;#39; in user copies for the FSRM case")<br /> 8c9b6a88b7e2 ("x86: improve on the non-rep &amp;#39;clear_user&amp;#39; function")<br /> 427fda2c8a49 ("x86: improve on the non-rep &amp;#39;copy_user&amp;#39; function")<br /> * e046fe5a36a9 ("x86: set FSRS automatically on AMD CPUs that have FSRM")<br /> e1f2750edc4a ("x86: remove &amp;#39;zerorest&amp;#39; argument from __copy_user_nocache()")<br /> 034ff37d3407 ("x86: rewrite &amp;#39;__copy_user_nocache&amp;#39; function")<br /> <br /> with either the whole series or at a minimum the two marked commits<br /> being needed to fix this issue ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: freescale: Fix a memory out of bounds when num_configs is 1<br /> <br /> The config passed in by pad wakeup is 1, when num_configs is 1,<br /> Configuration [1] should not be fetched, which will be detected<br /> by KASAN as a memory out of bounds condition. Modify to get<br /> configs[1] when num_configs is 2.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix potential use-after-free bugs in TCP_Server_Info::hostname<br /> <br /> TCP_Server_Info::hostname may be updated once or many times during<br /> reconnect, so protect its access outside reconnect path as well and<br /> then prevent any potential use-after-free bugs.