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

nvme-multipath: fix lockdep WARN due to partition scan work

Blktests test cases nvme/014, 057 and 058 fail occasionally due to a
lockdep WARN. As reported in the Closes tag URL, the WARN indicates that
a deadlock can happen due to the dependency among disk->open_mutex,
kblockd workqueue completion and partition_scan_work completion.

To avoid the lockdep WARN and the potential deadlock, cut the dependency
by running the partition_scan_work not by kblockd workqueue but by
nvme_wq.
References: https://git.kernel.org/stable/c/6d87cd[PII_REDACTED]280f82c47cc8a657271929c3; https://git.kernel.org/stable/c/89456dab7ba5ab63d[PII_REDACTED]6673a3205e829; https://git.kernel.org/stable/c/b03eb63288a8ffe3adfb34e68309c8e2edb06d0b
CVE: CVE-2025-68219
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix memory leak in smb3_fs_context_parse_param error path

Add proper cleanup of ctx->source and fc->source to the
cifs_parse_mount_err error handler. This ensures that memory allocated
for the source strings is correctly freed on all error paths, matching
the cleanup already performed in the success path by
smb3_cleanup_fs_context_contents().
Pointers are also set to NULL after freeing to prevent potential
double-free issues.

This change fixes a memory leak originally detected by syzbot. The
leak occurred when processing Opt_source mount options if an error
happened after ctx->source and fc->source were successfully
allocated but before the function completed.

The specific leak sequence was:
1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory
2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory
3. A subsequent error jumps to cifs_parse_mount_err
4. The old error handler freed passwords but not the source strings,
causing the memory to leak.

This issue was not addressed by commit e8c73eb7db0a ("cifs: client:
fix memory leak in smb3_fs_context_parse_param"), which only fixed
leaks from repeated fsconfig() calls but not this error path.

Patch updated with minor change suggested by kernel test robot
References: https://git.kernel.org/stable/c/37010021d7e0341bb241ca00bcbae31f2c50b23f; https://git.kernel.org/stable/c/48d[PII_REDACTED]1f988e72edddd9688c20515421d; https://git.kernel.org/stable/c/7627864dc3121f39e220f5253a227edf472de59e
CVE: CVE-2025-68220
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error

Make knav_dma_open_channel consistently return NULL on error instead
of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h
returns NULL when the driver is disabled, but the driver
implementation does not even return NULL or ERR_PTR on failure,
causing inconsistency in the users. This results in a crash in
netcp_free_navigator_resources as followed (trimmed):

Unhandled fault: alignment exception (0x221) at 0xfffffff2
[fffffff2] *pgd=[PII_REDACTED]7003, *pmd=82ffda003, *pte=00000000
Internal error: : 221 [#1] SMP ARM
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE
Hardware name: Keystone
PC is at knav_dma_close_channel+0x30/0x19c
LR is at netcp_free_navigator_resources+0x2c/0x28c

[... TRIM...]

Call trace:
 knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c
 netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c
 netcp_ndo_open from __dev_open+0x114/0x29c
 __dev_open from __dev_change_flags+0x190/0x208
 __dev_change_flags from netif_change_flags+0x1c/0x58
 netif_change_flags from dev_change_flags+0x38/0xa0
 dev_change_flags from ip_auto_config+0x2c4/0x11f0
 ip_auto_config from do_one_initcall+0x58/0x200
 do_one_initcall from kernel_init_freeable+0x1cc/0x238
 kernel_init_freeable from kernel_init+0x1c/0x12c
 kernel_init from ret_from_fork+0x14/0x38
[... TRIM...]

Standardize the error handling by making the function return NULL on
all error conditions. The API is used in just the netcp_core.c so the
impact is limited.

Note, this change, in effect reverts commit 5b6cb43b4d62 ("net:
ethernet: ti: netcp_core: return error while dma channel open issue"),
but provides a less error prone implementation.
References: https://git.kernel.org/stable/c/2572c358ee434ce4b994472cceeb4043cbff5bc5; https://git.kernel.org/stable/c/3afeb909c3e2e0eb19b1e20506196e5f2d9c2259; https://git.kernel.org/stable/c/8427218ecbd7f8559c37972e66cb0fa06e82353b
CVE: CVE-2025-68221
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix address removal logic in mptcp_pm_nl_rm_addr

Fix inverted WARN_ON_ONCE condition that prevented normal address
removal counter updates. The current code only executes decrement
logic when the counter is already 0 (abnormal state), while
normal removals (counter > 0) are ignored.
References: https://git.kernel.org/stable/c/92e239e36d[PII_REDACTED]74994a545fcfac9afd2d; https://git.kernel.org/stable/c/f7d953c38245c0e9d8e268fb6a9e524602fb44ec
CVE: CVE-2025-68222
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_desc

s32_pinctrl_desc is allocated with devm_kmalloc(), but not all of its
fields are initialized. Notably, num_custom_params is used in
pinconf_generic_parse_dt_config(), resulting in intermittent allocation
errors, such as the following splat when probing i2c-imx:

        WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300
        [...]
        Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT)
        [...]
        Call trace:
         __alloc_pages_noprof+0x290/0x300 (P)
         ___kmalloc_large_node+0x84/0x168
         __kmalloc_large_node_noprof+0x34/0x120
         __kmalloc_noprof+0x2ac/0x378
         pinconf_generic_parse_dt_config+0x68/0x1a0
         s32_dt_node_to_map+0x104/0x248
         dt_to_map_one_config+0x154/0x1d8
         pinctrl_dt_to_map+0x12c/0x280
         create_pinctrl+0x6c/0x270
         pinctrl_get+0xc0/0x170
         devm_pinctrl_get+0x50/0xa0
         pinctrl_bind_pins+0x60/0x2a0
         really_probe+0x60/0x3a0
        [...]
         __platform_driver_register+0x2c/0x40
         i2c_adap_imx_init+0x28/0xff8 [i2c_imx]
        [...]

This results in later parse failures that can cause issues in dependent
drivers:

        s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property
        s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property
        [...]
        pca953x 0-0022: failed writing register: -6
        i2c i2c-0: IMX I2C adapter registered
        s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property
        s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property
        i2c i2c-1: IMX I2C adapter registered
        s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property
        s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property
        i2c i2c-2: IMX I2C adapter registered

Fix this by initializing s32_pinctrl_desc with devm_kzalloc() instead of
devm_kmalloc() in s32_pinctrl_probe(), which sets the previously
uninitialized fields to zero.
References: https://git.kernel.org/stable/c/3b90bd8aaeb21b513ecc4ed03299e80ece44a333; https://git.kernel.org/stable/c/583ac7f65791ceda38ea1a493a4859f7161dcb03; https://git.kernel.org/stable/c/7bbdd6c30e8fd92f7165b7730b038cfe42102004
CVE: CVE-2025-68223
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: delete radeon_fence_process in is_signaled, no deadlock

Delete the attempt to progress the queue when checking if fence is
signaled. This avoids deadlock.

dma-fence_ops::signaled can be called with the fence lock in unknown
state. For radeon, the fence lock is also the wait queue lock. This can
cause a self deadlock when signaled() tries to make forward progress on
the wait queue. But advancing the queue is unneeded because incorrectly
returning false from signaled() is perfectly acceptable.

(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/73bc12d6a547f9571ce4393acfd73c004e2df9e5; https://git.kernel.org/stable/c/7e3e9b3a44c23c8eac86a41308c05077d6d30f41; https://git.kernel.org/stable/c/9d0ed508a9e2af82951ce7d834f58c139fc2bd9b
CVE: CVE-2025-68224
Published: 2025-12-16
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-68225
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

lib/test_kho: check if KHO is enabled

We must check whether KHO is enabled prior to issuing KHO commands,
otherwise KHO internal data structures are not initialized.
References: https://git.kernel.org/stable/c/a26ec8f3d4e56d4a7ffa301e8032dca9df0bbc05; https://git.kernel.org/stable/c/bb3267bedd902ec457643b1326cccddafb82e901
CVE: CVE-2025-68226
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix incomplete backport in cfids_invalidation_worker()

The previous commit bdb596ceb4b7 ("smb: client: fix potential UAF in
smb2_close_cached_fid()") was an incomplete backport and missed one
kref_put() call in cfids_invalidation_worker() that should have been
converted to close_cached_dir().
References: https://git.kernel.org/stable/c/abd29b6e17a918fdd68352ce4813e167acc8727e
CVE: CVE-2025-68227
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: Fix proto fallback detection with BPF

The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap's custom read/write interfaces.
'''
tcp_rcv_state_process()
  syn_recv_sock()/subflow_syn_recv_sock()
    tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
      bpf_skops_established       <== sockops
        bpf_sock_map_update(sk)   <== call bpf helper
          tcp_bpf_update_proto()  <== update sk_prot
'''

When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk's sk_prot with the native sk_prot.
'''
subflow_syn_recv_sock()
  subflow_ulp_fallback()
    subflow_drop_ctx()
      mptcp_subflow_ops_undo_override()
'''

Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap's custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk->sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk->sk_socket->ops.

This fix uses the more generic sk_family for the comparison instead.

Additionally, this also prevents a WARNING from occurring:

result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
(net/mptcp/protocol.c:4005)
Modules linked in:
...

PKRU: 55555554
Call Trace:
<TASK>
do_accept (net/socket.c:1989)
__sys_accept4 (net/socket.c:2028 net/socket.c:2057)
__x64_sys_accept (net/socket.c:2067)
x64_sys_call (arch/x86/entry/syscall_64.c:41)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f87ac92b83d

---[ end trace [PII_REDACTED] ]---
References: https://git.kernel.org/stable/c/037cc[PII_REDACTED]2d69185b663ecf9d26cce91e8; https://git.kernel.org/stable/c/1a0d5c74af9b6ba9ffdf1172de5a1a6df5922a00; https://git.kernel.org/stable/c/344974ea1a3ca30e4920687b0091bda4438cebdb
CVE: CVE-2025-68228
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/plane: Fix create_in_format_blob() return value

create_in_format_blob() is either supposed to return a valid
pointer or an error, but never NULL. The caller will dereference
the blob when it is not an error, and thus will oops if NULL
returned. Return proper error values in the failure cases.
References: https://git.kernel.org/stable/c/860f93f4fce1e733b8a2474f6bfa153243d775f3; https://git.kernel.org/stable/c/cead55e24cf9e092890cf51c0548eccd7569defa
CVE: CVE-2025-68229
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()

If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we
attempt to dereference it in tcm_loop_tpg_address_show() we will get a
segfault, see below for an example. So, check tl_hba->sh before
dereferencing it.

  Unable to allocate struct scsi_host
  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1
  Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024
  RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]
...
  Call Trace:
   <TASK>
   configfs_read_iter+0x12d/0x1d0 [configfs]
   vfs_read+0x1b5/0x300
   ksys_read+0x6f/0xf0
...
References: https://git.kernel.org/stable/c/13aff3b8a7184281b134698704d6c06863a8361b; https://git.kernel.org/stable/c/1c9ba455b5073253ceaadae4859546e38e8261fe; https://git.kernel.org/stable/c/3d8c517f6eb27e47b1a198e05f[PII_REDACTED]b40b
CVE: CVE-2025-68230
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix gpu page fault after hibernation on PF passthrough

On PF passthrough environment, after hibernate and then resume, coralgemm
will cause gpu page fault.

Mode1 reset happens during hibernate, but partition mode is not restored
on resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not right
after resume. When CP access the MQD BO, wrong stride size is used,
this will cause out of bound access on the MQD BO, resulting page fault.

The fix is to ensure gfx_v9_4_3_switch_compute_partition() is called
when resume from a hibernation.
KFD resume is called separately during a reset recovery or resume from
suspend sequence. Hence it's not required to be called as part of
partition switch.

(cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)
References: https://git.kernel.org/stable/c/a45d6359eefb41e08d374a3260b10bff5626823b; https://git.kernel.org/stable/c/eb6e7f520d6efa4d4ebf1671455abe4a681f7a05; https://git.kernel.org/stable/c/eef72d856f978955e633c270abb1f7ec7b61c6d2
CVE: CVE-2025-68231
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/mempool: fix poisoning order>0 pages with HIGHMEM

The kernel test has reported:

  BUG: unable to handle page fault for address: fffba000
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0002) - not-present page
  *pde = 03171067 *pte = 00000000
  Oops: Oops: 0002 [#1]
  CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE  a1d066dfe789f54bc7645c7989957d2bdee593ca
  Tainted: [T]=RANDSTRUCT
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
  EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)
  Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56
  EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b
  ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8
  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287
  CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690
  Call Trace:
   poison_element (mm/mempool.c:83 mm/mempool.c:102)
   mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)
   mempool_init_noprof (mm/mempool.c:250 (discriminator 1))
   ? mempool_alloc_pages (mm/mempool.c:640)
   bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))
   ? mempool_alloc_pages (mm/mempool.c:640)
   do_one_initcall (init/main.c:1283)

Christoph found out this is due to the poisoning code not dealing
properly with CONFIG_HIGHMEM because only the first page is mapped but
then the whole potentially high-order page is accessed.

We could give up on HIGHMEM here, but it's straightforward to fix this
with a loop that's mapping, poisoning or checking and unmapping
individual pages.
References: https://git.kernel.org/stable/c/19de79aaea33ee1ea058c8711b3b2b4a7e4decd4; https://git.kernel.org/stable/c/6a13b56537e7b0d97f4bb74e8038ce471f9770d7; https://git.kernel.org/stable/c/a79e49e1704367b635edad1479db23d7cf1fb71a
CVE: CVE-2025-68232
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

veth: more robust handing of race to avoid txq getting stuck

Commit dc82a33297fc ("veth: apply qdisc backpressure on full ptr_ring to
reduce TX drops") introduced a race condition that can lead to a permanently
stalled TXQ. This was observed in production on ARM64 systems (Ampere Altra
Max).

The race occurs in veth_xmit(). The producer observes a full ptr_ring and
stops the queue (netif_tx_stop_queue()). The subsequent conditional logic,
intended to re-wake the queue if the consumer had just emptied it (if
(__ptr_ring_empty(...)) netif_tx_wake_queue()), can fail. This leads to a
"lost wakeup" where the TXQ remains stopped (QUEUE_STATE_DRV_XOFF) and
traffic halts.

This failure is caused by an incorrect use of the __ptr_ring_empty() API
from the producer side. As noted in kernel comments, this check is not
guaranteed to be correct if a consumer is operating on another CPU. The
empty test is based on ptr_ring->consumer_head, making it reliable only for
the consumer. Using this check from the producer side is fundamentally racy.

This patch fixes the race by adopting the more robust logic from an earlier
version V4 of the patchset, which always flushed the peer:

(1) In veth_xmit(), the racy conditional wake-up logic and its memory barrier
are removed. Instead, after stopping the queue, we unconditionally call
__veth_xdp_flush(rq). This guarantees that the NAPI consumer is scheduled,
making it solely responsible for re-waking the TXQ.
  This handles the race where veth_poll() consumes all packets and completes
NAPI *before* veth_xmit() on the producer side has called netif_tx_stop_queue.
The __veth_xdp_flush(rq) will observe rx_notify_masked is false and schedule
NAPI.

(2) On the consumer side, the logic for waking the peer TXQ is moved out of
veth_xdp_rcv() and placed at the end of the veth_poll() function. This
placement is part of fixing the race, as the netif_tx_queue_stopped() check
must occur after rx_notify_masked is potentially set to false during NAPI
completion.
  This handles the race where veth_poll() consumes all packets, but haven't
finished (rx_notify_masked is still true). The producer veth_xmit() stops the
TXQ and __veth_xdp_flush(rq) will observe rx_notify_masked is true, meaning
not starting NAPI.  Then veth_poll() change rx_notify_masked to false and
stops NAPI.  Before exiting veth_poll() will observe TXQ is stopped and wake
it up.
References: https://git.kernel.org/stable/c/5442a9da69789741bfda39f34ee7f69552bf0c56; https://git.kernel.org/stable/c/6c8a8b9257a660e622689e23c8fbad4ba2b561b9; https://git.kernel.org/stable/c/dd419a3f2ebc18cc00bc32c57fd052d7a188b78b
CVE: CVE-2025-68233
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/tegra: Add call to put_pid()

Add a call to put_pid() corresponding to get_task_pid().
host1x_memory_context_alloc() does not take ownership of the PID so we
need to free it here to avoid leaking.

[mperttunen@nvidia.com: reword commit message]
References: https://git.kernel.org/stable/c/27ea5c2c75c3419a9a019240ca44b9256f628df1; https://git.kernel.org/stable/c/2e78580e6e7deac6556236ef96db5bbf7b46857e; https://git.kernel.org/stable/c/6b572e5154af08ee13f8d2673e86f83bc5ff86cd
CVE: CVE-2025-68234
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/cmd_net: fix wrong argument types for skb_queue_splice()

If timestamp retriving needs to be retried and the local list of
SKB's already has entries, then it's spliced back into the socket
queue. However, the arguments for the splice helper are transposed,
causing exactly the wrong direction of splicing into the on-stack
list. Fix that up.
References: https://git.kernel.org/stable/c/46447367a52965e9d35f112f5b26fc8ff8ec443d; https://git.kernel.org/stable/c/c85d2cfc5e24e6866b56c7253fd4e1c7db35986c
CVE: CVE-2025-68235
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::boot

nvkm_falcon_fw::boot is allocated, but no one frees it. This causes a
kmemleak warning.

Make sure this data is deallocated.
References: https://git.kernel.org/stable/c/2bba02a39bfb383bd1a95868d532c0917e38f9e7; https://git.kernel.org/stable/c/6492add9a3a163d5e0390428d2636adc3e61b883; https://git.kernel.org/stable/c/7d1977b4ae5c50e1aafc5c51500fc08bd7afd6a0
CVE: CVE-2025-68236
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)

According to UFS specifications, the power-off sequence for a UFS device
includes:

 - Sending an SSU command with Power_Condition=3 and await a response.

 - Asserting RST_N low.

 - Turning off REF_CLK.

 - Turning off VCC.

 - Turning off VCCQ/VCCQ2.

As part of ufs shutdown, after the SSU command completion, asserting
hardware reset (HWRST) triggers the device firmware to wake up and
execute its reset routine. This routine initializes hardware blocks and
takes a few milliseconds to complete. During this time, the ICCQ draws a
large current.

This large ICCQ current may cause issues for the regulator which is
supplying power to UFS, because the turn off request from UFS driver to
the regulator framework will be immediately followed by low power
mode(LPM) request by regulator framework. This is done by framework
because UFS which is the only client is requesting for disable. So if
the rail is still in the process of shutting down while ICCQ exceeds LPM
current thresholds, and LPM mode is activated in hardware during this
state, it may trigger an overcurrent protection (OCP) fault in the
regulator.

To prevent this, a 10ms delay is added after asserting HWRST. This
allows the reset operation to complete while power rails remain active
and in high-power mode.

Currently there is no way for Host to query whether the reset is
completed or not and hence this the delay is based on experiments with
Qualcomm UFS controllers across multiple UFS vendors.
References: https://git.kernel.org/stable/c/5127be409c6c3815c4a7d8f6d88043e44f9b9543; https://git.kernel.org/stable/c/b712f234a74c1f5ce70b5d7aec3fc2499c258141