Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> FS: JFS: Check for read-only mounted filesystem in txBegin<br /> <br /> This patch adds a check for read-only mounted filesystem<br /> in txBegin before starting a transaction potentially saving<br /> from NULL pointer deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix memory leak in ath12k_qmi_driver_event_work()<br /> <br /> Currently the buffer pointed by event is not freed in case<br /> ATH12K_FLAG_UNREGISTERING bit is set, this causes memory leak.<br /> <br /> Add a goto skip instead of return, to ensure event and all the<br /> list entries are freed properly.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regmap-irq: Fix out-of-bounds access when allocating config buffers<br /> <br /> When allocating the 2D array for handling IRQ type registers in<br /> regmap_add_irq_chip_fwnode(), the intent is to allocate a matrix<br /> with num_config_bases rows and num_config_regs columns.<br /> <br /> This is currently handled by allocating a buffer to hold a pointer for<br /> each row (i.e. num_config_bases). After that, the logic attempts to<br /> allocate the memory required to hold the register configuration for<br /> each row. However, instead of doing this allocation for each row<br /> (i.e. num_config_bases allocations), the logic erroneously does this<br /> allocation num_config_regs number of times.<br /> <br /> This scenario can lead to out-of-bounds accesses when num_config_regs<br /> is greater than num_config_bases. Fix this by updating the terminating<br /> condition of the loop that allocates the memory for holding the register<br /> configuration to allocate memory only for each row in the matrix.<br /> <br /> Amit Pundir reported a crash that was occurring on his db845c device<br /> due to memory corruption (see "Closes" tag for Amit&amp;#39;s report). The KASAN<br /> report below helped narrow it down to this issue:<br /> <br /> [ 14.033877][ T1] ==================================================================<br /> [ 14.042507][ T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364<br /> [ 14.050796][ T1] Write of size 8 at addr 06ffff8081021850 by task init/1<br /> <br /> [ 14.242004][ T1] The buggy address belongs to the object at ffffff8081021850<br /> [ 14.242004][ T1] which belongs to the cache kmalloc-8 of size 8<br /> [ 14.255669][ T1] The buggy address is located 0 bytes inside of<br /> [ 14.255669][ T1] 8-byte region [ffffff8081021850, ffffff8081021858)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virt/coco/sev-guest: Double-buffer messages<br /> <br /> The encryption algorithms read and write directly to shared unencrypted<br /> memory, which may leak information as well as permit the host to tamper<br /> with the message integrity. Instead, copy whole messages in or out as<br /> needed before doing any computation on them.

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.

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