deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50630
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: hugetlb: fix UAF in hugetlb_handle_userfault

The vma_lock and hugetlb_fault_mutex are dropped before handling userfault
and reacquire them again after handle_userfault(), but reacquire the
vma_lock could lead to UAF[1,2] due to the following race,

hugetlb_fault
  hugetlb_no_page
    /*unlock vma_lock */
    hugetlb_handle_userfault
      handle_userfault
        /* unlock mm->mmap_lock*/
                                           vm_mmap_pgoff
                                             do_mmap
                                               mmap_region
                                                 munmap_vma_range
                                                   /* clean old vma */
        /* lock vma_lock again  <--- UAF */
    /* unlock vma_lock */

Since the vma_lock will unlock immediately after
hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in
hugetlb_handle_userfault() to fix the issue.

[1] https://lore.kernel.org/linux-mm/[PII_REDACTED]00d5e00a05e834962e@google.com/
[2] https://lore.kernel.org/linux-mm/[PII_REDACTED]4457.1668-1-liuzixian4@huawei.com/
References: https://git.kernel.org/stable/c/0db2efb3bff879566f05341d94c3de00ac95c4cc; https://git.kernel.org/stable/c/45c33966759ea1b4040c08dacda99ef623c0ca29; https://git.kernel.org/stable/c/78504bcedb2f1bbfb353b4d233c24d641c4dda33
CVE: CVE-2023-53743
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: Free released resource after coalescing

release_resource() doesn't actually free the resource or resource list
entry so free the resource list entry to avoid a leak.
References: https://git.kernel.org/stable/c/4443f3695d581ad1a55f2ef59259dcd0c52402b3; https://git.kernel.org/stable/c/8ec9c1d5d0a5a4744516adb483b97a238892f9d5; https://git.kernel.org/stable/c/a076e73dd6e619729e1af8d0d802fe52ac5eb2b3
CVE: CVE-2023-53744
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: ti: pm33xx: Fix refcount leak in am33xx_pm_probe

wkup_m3_ipc_get() takes refcount, which should be freed by
wkup_m3_ipc_put(). Add missing refcount release in the error paths.
References: https://git.kernel.org/stable/c/08310f810975c8c9e17c6ffb99fdb76a84e8adb7; https://git.kernel.org/stable/c/65305e8c0009a1933679dad5c8196060a10f3c8b; https://git.kernel.org/stable/c/6a50350033e0e0854acf59a8413913b4de04bd7d
CVE: CVE-2023-53745
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

um: vector: Fix memory leak in vector_config

If the return value of the uml_parse_vector_ifspec function is NULL,
we should call kfree(params) to prevent memory leak.
References: https://git.kernel.org/stable/c/276a7298af6a801e9a865282605a79303365ec66; https://git.kernel.org/stable/c/5c49fb5ad01104acc584405572abf6616d45148e; https://git.kernel.org/stable/c/634a9c139cc1362f6a9cc6cbfe442dbb60ff9f3f
CVE: CVE-2023-53746
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/vfio-ap: fix memory leak in vfio_ap device driver

The device release callback function invoked to release the matrix device
uses the dev_get_drvdata(device *dev) function to retrieve the
pointer to the vfio_matrix_dev object in order to free its storage. The
problem is, this object is not stored as drvdata with the device; since the
kfree function will accept a NULL pointer, the memory for the
vfio_matrix_dev object is never freed.

Since the device being released is contained within the vfio_matrix_dev
object, the container_of macro will be used to retrieve its pointer.
References: https://git.kernel.org/stable/c/5195de1d5f66b276683240a896783f7f43c4f664; https://git.kernel.org/stable/c/6a40fda14b4be3e38f03cc42ffd4efbc64fb3e67; https://git.kernel.org/stable/c/7b6a02f5bf15931464c79dfd487c57f76aae3496
CVE: CVE-2023-53747
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF

After a call to console_unlock() in vcs_write() the vc_data struct can be
freed by vc_port_destruct(). Because of that, the struct vc_data pointer
must be reloaded in the while loop in vcs_write() after console_lock() to
avoid a UAF when vcs_size() is called.

Syzkaller reported a UAF in vcs_size().

BUG: KASAN: slab-use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)
Read of size 4 at addr ffff8880beab89a8 by task repro_vcs_size/4119

Call Trace:
 <TASK>
__asan_report_load4_noabort (mm/kasan/report_generic.c:380)
vcs_size (drivers/tty/vt/vc_screen.c:215)
vcs_write (drivers/tty/vt/vc_screen.c:664)
vfs_write (fs/read_write.c:582 fs/read_write.c:564)
...
 <TASK>

Allocated by task 1213:
kmalloc_trace (mm/slab_common.c:1064)
vc_allocate (./include/linux/slab.h:559 ./include/linux/slab.h:680
    drivers/tty/vt/vt.c:1078 drivers/tty/vt/vt.c:1058)
con_install (drivers/tty/vt/vt.c:3334)
tty_init_dev (drivers/tty/tty_io.c:1303 drivers/tty/tty_io.c:1415
    drivers/tty/tty_io.c:1392)
tty_open (drivers/tty/tty_io.c:2082 drivers/tty/tty_io.c:2128)
chrdev_open (fs/char_dev.c:415)
do_dentry_open (fs/open.c:921)
vfs_open (fs/open.c:1052)
...

Freed by task 4116:
kfree (mm/slab_common.c:1016)
vc_port_destruct (drivers/tty/vt/vt.c:1044)
tty_port_destructor (drivers/tty/tty_port.c:296)
tty_port_put (drivers/tty/tty_port.c:312)
vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))
vt_ioctl (drivers/tty/vt/vt_ioctl.c:903)
tty_ioctl (drivers/tty/tty_io.c:2778)
...

The buggy address belongs to the object at ffff8880beab8800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 424 bytes inside of
 freed 1024-byte region [ffff8880beab8800, ffff8880beab8c00)

The buggy address belongs to the physical page:
page:00000000afc77580 refcount:1 mapcount:0 mapping:[PII_REDACTED]
    index:0x0 pfn:0xbeab8
head:00000000afc77580 order:3 entire_mapcount:0 nr_pages_mapped:0
    pincount:0
flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
page_type: 0xffffffff()
raw: 000fffffc0010200 ffff888100042dc0 ffffea000426de00 dead[PII_REDACTED]02
raw: [PII_REDACTED] [PII_REDACTED] 00000001ffffffff [PII_REDACTED]
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8880beab8880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8880beab8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff8880beab8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
 ffff8880beab8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8880beab8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint
References: https://git.kernel.org/stable/c/0deff678157333d775af190f84696336cdcccd6d; https://git.kernel.org/stable/c/11dddfbb7a4e62489b01074d6c04d9d1b42e4047; https://git.kernel.org/stable/c/1de42e7653d6714a7507ba6696151a1fa028c69f
CVE: CVE-2023-53748
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setup

variable *nplanes is provided by user via system call argument. The
possible value of q_data->fmt->num_planes is 1-3, while the value
of *nplanes can be 1-8. The array access by index i can cause array
out-of-bounds.

Fix this bug by checking *nplanes against the array size.
References: https://git.kernel.org/stable/c/48e4e06e2c5fe1fda283d499f91492eda2248bb9; https://git.kernel.org/stable/c/8fbcf730cb89c3647f3365226fe7014118fa93c7; https://git.kernel.org/stable/c/b8e19bf3b4aebd855be01b64674187dcf6d1db51
CVE: CVE-2023-53749
Published: 2025-12-08
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53750
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: freescale: Fix a memory out of bounds when num_configs is 1

The config passed in by pad wakeup is 1, when num_configs is 1,
Configuration [1] should not be fetched, which will be detected
by KASAN as a memory out of bounds condition. Modify to get
configs[1] when num_configs is 2.
References: https://git.kernel.org/stable/c/27d9a7585b594bb2f9bb1f65e0003814fcc69c75; https://git.kernel.org/stable/c/9063777ca1e2e895c5fdd493ee0c3f18fa710ed4; https://git.kernel.org/stable/c/f85d3cb10f4df5ae3bdb9a9357315c28d781651f
CVE: CVE-2023-53751
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix potential use-after-free bugs in TCP_Server_Info::hostname

TCP_Server_Info::hostname may be updated once or many times during
reconnect, so protect its access outside reconnect path as well and
then prevent any potential use-after-free bugs.
References: https://git.kernel.org/stable/c/0b08c4c499200be67d54c439d56e5ea866869945; https://git.kernel.org/stable/c/64d62ac6d6514cba1305bd08e271ec1843bdd612; https://git.kernel.org/stable/c/90c49fce1c43e1cc152695e20363ff5087897c09
CVE: CVE-2023-53752
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

net: deal with integer overflows in kmalloc_reserve()

Blamed commit changed:
    ptr = kmalloc(size);
    if (ptr)
      size = ksize(ptr);

    size = kmalloc_size_roundup(size);
    ptr = kmalloc(size);

This allowed various crash as reported by syzbot [1]
and Kyle Zeng.

Problem is that if @size is bigger than 0x80000001,
kmalloc_size_roundup(size) returns 2^32.

kmalloc_reserve() uses a 32bit variable (obj_size),
so 2^32 is truncated to 0.

kmalloc(0) returns ZERO_SIZE_PTR which is not handled by
skb allocations.

Following trace can be triggered if a netdev->mtu is set
close to 0x7fffffff

We might in the future limit netdev->mtu to more sensible
limit (like KMALLOC_MAX_SIZE).

This patch is based on a syzbot report, and also a report
and tentative fix from Kyle Zeng.

[1]
BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]
BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554

CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023
Call trace:
dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279
show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106
print_report+0xe4/0x4b4 mm/kasan/report.c:398
kasan_report+0x150/0x1ac mm/kasan/report.c:495
kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189
memset+0x40/0x70 mm/kasan/shadow.c:44
__build_skb_around net/core/skbuff.c:294 [inline]
__alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527
alloc_skb include/linux/skbuff.h:1316 [inline]
igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359
add_grec+0x81c/0x1124 net/ipv4/igmp.c:534
igmpv3_send_cr net/ipv4/igmp.c:667 [inline]
igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810
call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474
expire_timers kernel/time/timer.c:1519 [inline]
__run_timers+0x54c/0x710 kernel/time/timer.c:1790
run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803
_stext+0x380/0xfbc
____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79
call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891
do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84
invoke_softirq kernel/softirq.c:437 [inline]
__irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683
irq_exit_rcu+0x14/0x78 kernel/softirq.c:695
el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717
__el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724
el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729
el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584
References: https://git.kernel.org/stable/c/31cf7853a940181593e4472fc56f46574123f9f6; https://git.kernel.org/stable/c/915d975b2ffa58a14bfcf16fafe00c41315949ff; https://git.kernel.org/stable/c/bf7da02d2b8faf324206e1cbe64a4813ff903cc1
CVE: CVE-2023-53753
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix mapping to non-allocated address

[Why]
There is an issue mapping non-allocated location of memory.
It would allocate gpio registers from an array out of bounds.

[How]
Patch correct numbers of bounds for using.
References: https://git.kernel.org/stable/c/24aaf6603600d6d1159973c809ea2737664b28c4; https://git.kernel.org/stable/c/8ce8a443ddd9002861a4ee8a7e33a0c02717422f; https://git.kernel.org/stable/c/9190d4a263264eabf715f5fc1827da45e3fdc247
CVE: CVE-2023-53754
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()

When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4)
returns false, drbl_regs_memmap_p is not remapped. This passes a NULL
pointer to iounmap(), which can trigger a WARN() on certain arches.

When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4)
returns true, drbl_regs_memmap_p may has been remapped and
ctrl_regs_memmap_p is not remapped. This is a resource leak and passes a
NULL pointer to iounmap().

To fix these issues, we need to add null checks before iounmap(), and
change some goto labels.
References: https://git.kernel.org/stable/c/631d0fab143bef85ea0813596f1dda36e2b9724c; https://git.kernel.org/stable/c/74d90f92eafe8ccd[PII_REDACTED]a28a94eda6bcc; https://git.kernel.org/stable/c/7e5a54d1f00725a739dcd20f616d82eff4f764bd
CVE: CVE-2023-53755
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ptdma: check for null desc before calling pt_cmd_callback

Resolves a panic that can occur on AMD systems, typically during host
shutdown, after the PTDMA driver had been exercised. The issue was
the pt_issue_pending() function is mistakenly assuming that there will
be at least one descriptor in the Submitted queue when the function
is called. However, it is possible that both the Submitted and Issued
queues could be empty, which could result in pt_cmd_callback() being
mistakenly called with a NULL pointer.
Ref: Bugzilla Bug 216856.
References: https://git.kernel.org/stable/c/5bba023b1241c7af5d40447503a68de282ad5190; https://git.kernel.org/stable/c/8ae[PII_REDACTED]207efc05453bc9a3df2b992bf45; https://git.kernel.org/stable/c/[PII_REDACTED]71a6f763b34b039427f5667ba3fd50
CVE: CVE-2023-53756
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: VMX: Fix crash due to uninitialized current_vmcs

KVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running as
a nested hypervisor on top of Hyper-V. When MSR bitmap is updated,
evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to mark
that the msr bitmap was changed.

vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr
-> vmx_msr_bitmap_l01_changed which in the end calls this function. The
function checks for current_vmcs if it is null but the check is
insufficient because current_vmcs is not initialized. Because of this, the
code might incorrectly write to the structure pointed by current_vmcs value
left by another task. Preemption is not disabled, the current task can be
preempted and moved to another CPU while current_vmcs is accessed multiple
times from evmcs_touch_msr_bitmap() which leads to crash.

The manipulation of MSR bitmaps by callers happens only for vmcs01 so the
solution is to use vmx->vmcs01.vmcs instead of current_vmcs.

  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  PGD 4e1775067 P4D 0
  Oops: 0002 [#1] PREEMPT SMP NOPTI
  ...
  RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel]
  ...
  Call Trace:
   vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel]
   vmx_vcpu_create+0xe6/0x540 [kvm_intel]
   kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm]
   kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm]
   kvm_vm_ioctl+0x53f/0x790 [kvm]
   __x64_sys_ioctl+0x8a/0xc0
   do_syscall_64+0x5c/0x90
   entry_SYSCALL_64_after_hwframe+0x63/0xcd
References: https://git.kernel.org/stable/c/3ba95cc671c025d0d2a1c7d5e2930f0ff0980cf4; https://git.kernel.org/stable/c/6baebcecf09acd19e2bab1c2911dcdba5d48a1dc; https://git.kernel.org/stable/c/6e7bc50f97c9855da83f1478f722590defd45ff2
CVE: CVE-2023-53757
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probe

of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak.
References: https://git.kernel.org/stable/c/4545d7a70ce0fc78b1d3c33c4a0939a86f363b57; https://git.kernel.org/stable/c/88cb93d3a16f706bd7213f8a5882c394e5d10c4e; https://git.kernel.org/stable/c/91e149b201bdb68c77011d50d011e47fadbcc8bd
CVE: CVE-2023-53758
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: atmel-quadspi: Free resources even if runtime resume failed in .remove()

An early error exit in atmel_qspi_remove() doesn't prevent the device
unbind. So this results in an spi controller with an unbound parent
and unmapped register space (because devm_ioremap_resource() is undone).
So using the remaining spi controller probably results in an oops.

Instead unregister the controller unconditionally and only skip hardware
access and clk disable.

Also add a warning about resume failing and return zero unconditionally.
The latter has the only effect to suppress a less helpful error message by
the spi core.
References: https://git.kernel.org/stable/c/618770d4d8e40b7f8ed9eb5f210cd9164dfac47d; https://git.kernel.org/stable/c/77806d7c9bebe40a8cdce2b8d30fbe6511745df8; https://git.kernel.org/stable/c/9448bc1dee65f86c0fe64d9dea8b410af0586886
CVE: CVE-2023-53759
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: hidraw: fix data race on device refcount

The hidraw_open() function increments the hidraw device reference
counter. The counter has no dedicated synchronization mechanism,
resulting in a potential data race when concurrently opening a device.

The race is a regression introduced by commit 8590222e4b02 ("HID:
hidraw: Replace hidraw device table mutex with a rwsem"). While
minors_rwsem is intended to protect the hidraw_table itself, by instead
acquiring the lock for writing, the reference counter is also protected.
This is symmetrical to hidraw_release().
References: https://git.kernel.org/stable/c/05b47034e2488c2924e5c032e20a1979d012b5b5; https://git.kernel.org/stable/c/879e79c3aead41b8aa2e91164354b30bd1c4ef3b; https://git.kernel.org/stable/c/944ee77dc6ec7b0afd8ec70ffc418b238c92f12b
CVE: CVE-2023-53760
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: mcq: Fix &hwq->cq_lock deadlock issue

When ufshcd_err_handler() is executed, CQ event interrupt can enter waiting
for the same lock. This can happen in ufshcd_handle_mcq_cq_events() and
also in ufs_mtk_mcq_intr(). The following warning message will be generated
when &hwq->cq_lock is used in IRQ context with IRQ enabled. Use
ufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave instead of spin_lock to
resolve the deadlock issue.

[name:lockdep&]WARNING: inconsistent lock state
[name:lockdep&]--------------------------------
[name:lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] takes:
  ffffff[PII_REDACTED] (&hwq->cq_lock){?.-.}-{2:2}, at:
ufshcd_mcq_poll_cqe_lock+0x30/0xe0
[name:lockdep&]{IN-HARDIRQ-W} state was registered at:
  lock_acquire+0x17c/0x33c
  _raw_spin_lock+0x5c/0x7c
  ufshcd_mcq_poll_cqe_lock+0x30/0xe0
  ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod]
  __handle_irq_event_percpu+0x140/0x3ec
  handle_irq_event+0x50/0xd8
  handle_fasteoi_irq+0x148/0x2b0
  generic_handle_domain_irq+0x4c/0x6c
  gic_handle_irq+0x58/0x134
  call_on_irq_stack+0x40/0x74
  do_interrupt_handler+0x84/0xe4
  el1_interrupt+0x3c/0x78
<snip>

Possible unsafe locking scenario:
       CPU0
       ----
  lock(&hwq->cq_lock);
  <Interrupt>
    lock(&hwq->cq_lock);
  *** DEADLOCK ***
2 locks held by kworker/u16:4/260:

[name:lockdep&]
 stack backtrace:
CPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S      W  OE
6.1.17-mainline-android14-2-g277223301adb #1
Workqueue: ufs_eh_wq_0 ufshcd_err_handler

 Call trace:
  dump_backtrace+0x10c/0x160
  show_stack+0x20/0x30
  dump_stack_lvl+0x98/0xd8
  dump_stack+0x20/0x60
  print_usage_bug+0x584/0x76c
  mark_lock_irq+0x488/0x510
  mark_lock+0x1ec/0x25c
  __lock_acquire+0x4d8/0xffc
  lock_acquire+0x17c/0x33c
  _raw_spin_lock+0x5c/0x7c
  ufshcd_mcq_poll_cqe_lock+0x30/0xe0
  ufshcd_poll+0x68/0x1b0
  ufshcd_transfer_req_compl+0x9c/0xc8
  ufshcd_err_handler+0x3bc/0xea0
  process_one_work+0x2f4/0x7e8
  worker_thread+0x234/0x450
  kthread+0x110/0x134
  ret_from_fork+0x10/0x20
References: https://git.kernel.org/stable/c/2ce8c49c7b53e0a2258b833eeab16a6d78f732d1; https://git.kernel.org/stable/c/948afc69615167a3c82430f99bfd046332b89912
CVE: CVE-2023-53761
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: usbtmc: Fix direction for 0-length ioctl control messages

The syzbot fuzzer found a problem in the usbtmc driver: When a user
submits an ioctl for a 0-length control transfer, the driver does not
check that the direction is set to OUT:

------------[ cut here ]------------
usb 3-1: BOGUS control dir, pipe 80000b80 doesn't match bRequestType fd
WARNING: CPU: 0 PID: 5100 at drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
Modules linked in:
CPU: 0 PID: 5100 Comm: syz-executor428 Not tainted 6.3.0-syzkaller-12049-g58390c8ce1bd #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
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 <0f> 0b e9 9f ee ff ff e8 ed 12 5c fb 0f b6 1d 12 8a 3c 08 31 ff 41
RSP: 0018:ffffc90003d2fb00 EFLAGS: 00010282
RAX: [PII_REDACTED] RBX: ffff8880789e9058 RCX: [PII_REDACTED]
RDX: ffff888029593b80 RSI: ffffffff814c1447 RDI: [PII_REDACTED]
RBP: ffff88801ea742f8 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ffff88802915e528
R13:[PII_REDACTED]0000fd R14:[PII_REDACTED]000b80 R15: ffff8880222b3100
FS: [PII_REDACTED]ca63c0(0000) GS:ffff8880b9800000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f9ef4d18150 CR3:[PII_REDACTED]e5b000 CR4:[PII_REDACTED]3506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
 usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
 usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1954 [inline]
 usbtmc_ioctl+0x1b3d/0x2840 drivers/usb/class/usbtmc.c:2097

To fix this, we must override the direction in the bRequestType field
of the control request structure when the length is 0.
References: https://git.kernel.org/stable/c/0ced12bdf624d8d8977ddb16eb130cd479d92bcf; https://git.kernel.org/stable/c/3b43d9df27a708f4079d518b879f517fea150a91; https://git.kernel.org/stable/c/50775a046c68e1d157d5e413cae2e5e00da1c463