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

netfilter: nf_tables: don't unregister hook when table is dormant

When nf_tables_updchain encounters an error, hook registration needs to
be rolled back.

This should only be done if the hook has been registered, which won't
happen when the table is flagged as dormant (inactive).

Just move the assignment into the registration block.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/03d1fb457b696c18fe15661440c4f052b2374e7e; https://git.kernel.org/stable/c/6134d1ea1e1408e8e7c8c26545b3b301cbdf1eda; https://git.kernel.org/stable/c/688c15017d5cd5aac882400782e7213d40dc3556
CVE: CVE-2025-22065
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

idpf: fix adapter NULL pointer dereference on reboot

With SRIOV enabled, idpf ends up calling into idpf_remove() twice.
First via idpf_shutdown() and then again when idpf_remove() calls into
sriov_disable(), because the VF devices use the idpf driver, hence the
same remove routine. When that happens, it is possible for the adapter
to be NULL from the first call to idpf_remove(), leading to a NULL
pointer dereference.

echo 1 > /sys/class/net/<netif>/device/sriov_numvfs
reboot

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
...
RIP: 0010:idpf_remove+0x22/0x1f0 [idpf]
...
? idpf_remove+0x22/0x1f0 [idpf]
? idpf_remove+0x1e4/0x1f0 [idpf]
pci_device_remove+0x3f/0xb0
device_release_driver_internal+0x19f/0x200
pci_stop_bus_device+0x6d/0x90
pci_stop_and_remove_bus_device+0x12/0x20
pci_iov_remove_virtfn+0xbe/0x120
sriov_disable+0x34/0xe0
idpf_sriov_configure+0x58/0x140 [idpf]
idpf_remove+0x1b9/0x1f0 [idpf]
idpf_shutdown+0x12/0x30 [idpf]
pci_device_shutdown+0x35/0x60
device_shutdown+0x156/0x200
...

Replace the direct idpf_remove() call in idpf_shutdown() with
idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform
the bulk of the cleanup, such as stopping the init task, freeing IRQs,
destroying the vports and freeing the mailbox. This avoids the calls to
sriov_disable() in addition to a small netdev cleanup, and destroying
workqueues, which don't seem to be required on shutdown.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/4c9106f4906a85f6b13542d862e423bcdc118cc3; https://git.kernel.org/stable/c/79618e952ef4dfa1a17ee0631d5549603fab58d8; https://git.kernel.org/stable/c/88a6d562e92a295648f8636acf2a6aa714241771
CVE: CVE-2025-22066
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: imx-card: Add NULL check in imx_card_probe()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
imx_card_probe() does not check for this case, which results in a NULL
pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/018e6cf2503e60087747b0ebc190e18b3640766f; https://git.kernel.org/stable/c/38253922a89a742e7e622f626b41c[PII_REDACTED]1; https://git.kernel.org/stable/c/4d8458e48ff135bddc402ad79821dc058ea163d0
CVE: CVE-2025-22067
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: cadence: Fix out-of-bounds array access in cdns_mrvl_xspi_setup_clock()

If requested_clk > 128, cdns_mrvl_xspi_setup_clock() iterates over the
entire cdns_mrvl_xspi_clk_div_list array without breaking out early,
causing 'i' to go beyond the array bounds.

Fix that by stopping the loop when it gets to the last entry, clamping
the clock to the minimum 6.25 MHz.

Fixes the following warning with an UBSAN kernel:

  vmlinux.o: warning: objtool: cdns_mrvl_xspi_setup_clock: unexpected end of section .text.cdns_mrvl_xspi_setup_clock
CVSS Score: 7.8 (HIGH)
CWE: CWE-129, CWE-129
References: https://git.kernel.org/stable/c/645f1813fe0dc96381c36b834131e643b798fd73; https://git.kernel.org/stable/c/7ba0847fa1c22e7801cebfe5f7b75aee4fae317e; https://git.kernel.org/stable/c/c1fb84e274cb6a2bce6ba5e65116c06e0b3ab275
CVE: CVE-2025-22068
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ublk: make sure ubq->canceling is set when queue is frozen

Now ublk driver depends on `ubq->canceling` for deciding if the request
can be dispatched via uring_cmd & io_uring_cmd_complete_in_task().

Once ubq->canceling is set, the uring_cmd can be done via ublk_cancel_cmd()
and io_uring_cmd_done().

So set ubq->canceling when queue is frozen, this way makes sure that the
flag can be observed from ublk_queue_rq() reliably, and avoids
use-after-free on uring_cmd.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/[PII_REDACTED]e7572c2d2627ed6384302f7672aa1d; https://git.kernel.org/stable/c/7e3497d7dacb5aee69dd9be842b778083cae0e75; https://git.kernel.org/stable/c/8741d0737921ec1c03cf59aebf4d01400c2b461a
CVE: CVE-2025-22069
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler

Naresh Kamboju reported a "Bad frame pointer" kernel warning while
running LTP trace ftrace_stress_test.sh in riscv. We can reproduce the
same issue with the following command:

```
$ cd /sys/kernel/debug/tracing
$ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events
$ echo 1 > events/fprobes/enable
$ echo 1 > tracing_on
$ sleep 1
```

And we can get the following kernel warning:

[  127.692888] ------------[ cut here ]------------
[  127.693755] Bad frame pointer: expected ff[PII_REDACTED]be50, received ba34c141e9594000
[  127.693755]   from func do_nanosleep return to ffffffff800ccb16
[  127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be
[  127.699894] Modules linked in:
[  127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32
[  127.701453] Hardware name: riscv-virtio,qemu (DT)
[  127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be
[  127.702032]  ra : ftrace_return_to_handler+0x1b2/0x1be
[  127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff[PII_REDACTED]bd10
[  127.702221]  gp : ffffffff819c12f8 tp : ff[PII_REDACTED]3100 t0 : 6e[PII_REDACTED]0000
[  127.702284]  t1 : [PII_REDACTED] t2 : 6e7566206d6f7266 s0 : ff[PII_REDACTED]bd80
[  127.702346]  s1 : ff[PII_REDACTED]2000 a0 :[PII_REDACTED]00007b a1 : ffffffff81894f20
[  127.702408]  a2 : [PII_REDACTED] a3 : fffffffffffffffe a4 : [PII_REDACTED]
[  127.702470]  a5 : [PII_REDACTED] a6 : [PII_REDACTED] a7 : [PII_REDACTED]
[  127.702530]  s2 : ba34c141e9594000 s3 : [PII_REDACTED] s4 : ff[PII_REDACTED]bdd0
[  127.702591]  s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : [PII_REDACTED]
[  127.702651]  s8 : 00007fff8adf5d10 s9 :[PII_REDACTED]00006d s10: [PII_REDACTED]
[  127.702710]  s11:[PII_REDACTED]7377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e
[  127.702769]  t5 : ffffffff819d89a0 t6 : ff[PII_REDACTED]bb18
[  127.702826] status: [PII_REDACTED] badaddr: [PII_REDACTED] cause: [PII_REDACTED]
[  127.703292] [<ffffffff8013b5e0>] ftrace_return_to_handler+0x1b2/0x1be
[  127.703760] [<ffffffff80017bce>] return_to_handler+0x16/0x26
[  127.704009] [<ffffffff80017bb8>] return_to_handler+0x0/0x26
[  127.704057] [<ffffffff800d3352>] common_nsleep+0x42/0x54
[  127.704117] [<ffffffff800d44a2>] __riscv_sys_clock_nanosleep+0xba/0x10a
[  127.704176] [<ffffffff80901c56>] do_trap_ecall_u+0x188/0x218
[  127.704295] [<ffffffff8090cc3e>] handle_exception+0x14a/0x156
[  127.705436] ---[ end trace [PII_REDACTED] ]---

The reason is that the stack layout for constructing argument for the
ftrace_return_to_handler in the return_to_handler does not match the
__arch_ftrace_regs structure of riscv, leading to unexpected results.
CVSS Score: 7.8 (HIGH)
CWE: CWE-668
References: https://git.kernel.org/stable/c/67a5ba8f742f247bc83e46dd2313c142b1383276; https://git.kernel.org/stable/c/78b39c587b8f6c[PII_REDACTED]8f9c08a75b1c7c37
CVE: CVE-2025-22070
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/9p: fix NULL pointer dereference on mkdir

When a 9p tree was mounted with option 'posixacl', parent directory had a
default ACL set for its subdirectories, e.g.:

  setfacl -m default:group:simpsons:rwx parentdir

then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in
function v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL
(since dafbe689736) even though the subsequent v9fs_set_create_acl() call
expects a valid non-NULL 'fid' pointer:

  [   37.273191] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  ...
  [   37.322338] Call Trace:
  [   37.323043]  <TASK>
  [   37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)
  [   37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714)
  [   37.325532] ? search_module_extables (kernel/module/main.c:3733)
  [   37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet
  [   37.328006] ? search_bpf_extables (kernel/bpf/core.c:804)
  [   37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538)
  [   37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574)
  [   37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet
  [   37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p
  [   37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p
  [   37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p
  [   37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p
  [   37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p
  [   37.338590] vfs_mkdir (fs/namei.c:4313)
  [   37.339535] do_mkdirat (fs/namei.c:4336)
  [   37.340465] __x64_sys_mkdir (fs/namei.c:4354)
  [   37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
  [   37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

Fix this by simply swapping the sequence of these two calls in
v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before
v9fs_fid_add().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/2139dea5c53e3bb63ac49a6901c85e525a80ee8a; https://git.kernel.org/stable/c/3f61ac7c65bdb26accb52f9db66313597e759821; https://git.kernel.org/stable/c/6517b395cb1e43fbf3962dd93e6fb4a5e5ab100e
CVE: CVE-2025-22071
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

spufs: fix a leak in spufs_create_context()

Leak fixes back in 2008 missed one case - if we are trying to set affinity
and spufs_mkdir() fails, we need to drop the reference to neighbor.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0f5cce3fc55b08ee4da3372baccf4bcd36a98396; https://git.kernel.org/stable/c/239ea3c34673b3244a499fd65771c47e5bffcbb0; https://git.kernel.org/stable/c/410c787d89c92df4215d7b1a338e2c1a8aba6b9b
CVE: CVE-2025-22072
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

spufs: fix gang directory lifetimes

prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have
a problem with gang lifetimes - creation of a gang returns opened
gang directory, which normally gets removed when that gets closed,
but if somebody has created a context belonging to that gang and
kept it alive until the gang got closed, removal failed and we
ended up with a leak.

Unfortunately, it had been fixed the wrong way.  Dentry of gang
directory was no longer pinned, and rmdir on close was gone.
One problem was that failure of open kept calling simple_rmdir()
as cleanup, which meant an unbalanced dput().  Another bug was
in the success case - gang creation incremented link count on
root directory, but that was no longer undone when gang got
destroyed.

Fix consists of
	* reverting the commit in question
	* adding a counter to gang, protected by ->i_rwsem
of gang directory inode.
	* having it set to 1 at creation time, dropped
in both spufs_dir_close() and spufs_gang_close() and bumped
in spufs_create_context(), provided that it's not 0.
	* using simple_recursive_removal() to take the gang
directory out when counter reaches zero.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/029d8c711f5e5fe8cf63e8a4a1a140a06e224e45; https://git.kernel.org/stable/c/324f280806aab28ef757aecc18df419676c10ef8; https://git.kernel.org/stable/c/880e7b3da2e765c1f90c94c0539be039e96c7062
CVE: CVE-2025-22073
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

spufs: fix a leak on spufs_new_file() failure

It's called from spufs_fill_dir(), and caller of that will do
spufs_rmdir() in case of failure.  That does remove everything
we'd managed to create, but... the problem dentry is still
negative.  IOW, it needs to be explicitly dropped.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0bd56e4e72c354b65c0a7e5ac1c09eca81949d5b; https://git.kernel.org/stable/c/132925bd6772d7614340fb755ac5415462ac8edd; https://git.kernel.org/stable/c/35f789ccebd69f6f9a1e0a9b85435003b2450065
CVE: CVE-2025-22074
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix r_count dec/increment mismatch

r_count is only increased when there is an oplock break wait,
so r_count inc/decrement are not paired. This can cause r_count
to become negative, which can lead to a problem where the ksmbd
thread does not terminate.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/20378cf48359f39dee0ef9b61470ebe77bd49c0d; https://git.kernel.org/stable/c/457db486203c90e10c3efc87fd45cc7000b1cd36; https://git.kernel.org/stable/c/4790bcb269e5d6d88200a67c54ae6d627332a3be
CVE: CVE-2025-22076
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: fix missing shutdown check

xfstests generic/730 test failed because after deleting the device
that still had dirty data, the file could still be read without
returning an error. The reason is the missing shutdown check in
->read_iter.

I also noticed that shutdown checks were missing from ->write_iter,
->splice_read, and ->mmap. This commit adds shutdown checks to all
of them.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/47e35366bc6fa3cf189a8305bce63992495f3efa; https://git.kernel.org/stable/c/4a9595eb024b8319957c178be3cdeed613ac0795; https://git.kernel.org/stable/c/539147585ca453db6e3d7a5cf3b9c[PII_REDACTED]d
CVE: CVE-2025-22077
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "smb: client: fix TCP timers deadlock after rmmod"

This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.

Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock after
rmmod") is intended to fix a null-ptr-deref in LOCKDEP, which is
mentioned as CVE-2024-54680, but is actually did not fix anything;
The issue can be reproduced on top of it. [0]

Also, it reverted the change by commit ef7134c7fc48 ("smb: client:
Fix use-after-free of network namespace.") and introduced a real
issue by reviving the kernel TCP socket.

When a reconnect happens for a CIFS connection, the socket state
transitions to FIN_WAIT_1.  Then, inet_csk_clear_xmit_timers_sync()
in tcp_close() stops all timers for the socket.

If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1
forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.

Usually, FIN can be retransmitted by the peer, but if the peer aborts
the connection, the issue comes into reality.

I warned about this privately by pointing out the exact report [1],
but the bogus fix was finally merged.

So, we should not stop the timers to finally kill the connection on
our side in that case, meaning we must not use a kernel socket for
TCP whose sk->sk_net_refcnt is 0.

The kernel socket does not have a reference to its netns to make it
possible to tear down netns without cleaning up every resource in it.

For example, tunnel devices use a UDP socket internally, but we can
destroy netns without removing such devices and let it complete
during exit.  Otherwise, netns would be leaked when the last application
died.

However, this is problematic for TCP sockets because TCP has timers to
close the connection gracefully even after the socket is close()d.  The
lifetime of the socket and its netns is different from the lifetime of
the underlying connection.

If the socket user does not maintain the netns lifetime, the timer could
be fired after the socket is close()d and its netns is freed up, resulting
in use-after-free.

Actually, we have seen so many similar issues and converted such sockets
to have a reference to netns.

That's why I converted the CIFS client socket to have a reference to
netns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope
of CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right
fix**.

Regarding the LOCKDEP issue, we can prevent the module unload by
bumping the module refcount when switching the LOCKDDEP key in
sock_lock_init_class_and_name(). [2]

For a while, let's revert the bogus fix.

Note that now we can use sk_net_refcnt_upgrade() for the socket
conversion, but I'll do so later separately to make backport easy.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/4b6f6bf1bde8d6045c389fda8d21c304dfe49384; https://git.kernel.org/stable/c/8dbf[PII_REDACTED]77703bff0106fc984576184d11; https://git.kernel.org/stable/c/95d2b9f693ff2a1180a23d7d59acc0c4e72f4c41
CVE: CVE-2025-22078
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: vchiq_arm: Fix possible NPR of keep-alive thread

In case vchiq_platform_conn_state_changed() is never called or fails before
driver removal, ka_thread won't be a valid pointer to a task_struct. So
do the necessary checks before calling kthread_stop to avoid a crash.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1817c4b[PII_REDACTED]4e5ff9a80a6e01adb7e7e81; https://git.kernel.org/stable/c/3db89bc6d973e2bcaa852f6409c98c228f39a926; https://git.kernel.org/stable/c/a915c896f95a989a7759a73f8c064f5dc3775175
CVE: CVE-2025-22079
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: validate l_tree_depth to avoid out-of-bounds access

The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is
limited to OCFS2_MAX_PATH_DEPTH.

Add a check to prevent out-of-bounds access if l_tree_depth has an invalid
value, which may occur when reading from a corrupted mounted disk [1].
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/11e24802e73362aa2948ee16b8fb4e32635d5b2a; https://git.kernel.org/stable/c/17c99ab3db2ba74096d36c69daa6e784e98fc0b8; https://git.kernel.org/stable/c/3d012ba4404a0bb517658699ba85e6abda386dc3
CVE: CVE-2025-22080
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Prevent integer overflow in hdr_first_de()

The "de_off" and "used" variables come from the disk so they both need to
check.  The problem is that on 32bit systems if they're both greater than
UINT_MAX - 16 then the check does work as intended because of an integer
overflow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/201a2bdda13b619c4927700ffe47d387a30ced50; https://git.kernel.org/stable/c/6bb81b94f7a9cba6bde9a905cef52a65317a8b04; https://git.kernel.org/stable/c/85615aa[PII_REDACTED]23fc690390fa74d17b36ae1
CVE: CVE-2025-22081
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix a couple integer overflows on 32bit systems

On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can
have an integer wrapping issue.  Fix it by using size_add().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/0538f52410b619737e663167b6a2b2d0bc1a589d; https://git.kernel.org/stable/c/0922d86a7a6032cb1694eab0b44b861bd33ba8d5; https://git.kernel.org/stable/c/0dfe700fbd3525f30a36ffbe390a5b9319bd009a
CVE: CVE-2025-22082
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: backend: make sure to NULL terminate stack buffer

Make sure to NULL terminate the buffer in
iio_backend_debugfs_write_reg() before passing it to sscanf(). It is a
stack variable so we should not assume it will 0 initialized.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/035b4989211dc1c8626e186d655ae8ca5141bb73; https://git.kernel.org/stable/c/04271a4d2740f98bbe36f82cd3d74677a839d1eb; https://git.kernel.org/stable/c/df3892e5e861c43d5612728ed259634675b8a71f
CVE: CVE-2025-22084
Published: 2025-04-16
Description: In the Linux kernel, the following vulnerability has been resolved:

w1: fix NULL pointer dereference in probe

The w1_uart_probe() function calls w1_uart_serdev_open() (which includes
devm_serdev_device_open()) before setting the client ops via
serdev_device_set_client_ops(). This ordering can trigger a NULL pointer
dereference in the serdev controller's receive_buf handler, as it assumes
serdev->ops is valid when SERPORT_ACTIVE is set.

This is similar to the issue fixed in commit 5e700b384ec1
("platform/chrome: cros_ec_uart: properly fix race condition") where
devm_serdev_device_open() was called before fully initializing the
device.

Fix the race by ensuring client ops are set before enabling the port via
w1_uart_serdev_open().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0dd6770a72f138dabea9eae87f3da6ffa68f0d06; https://git.kernel.org/stable/c/4f750b84628080ff0d67bf1af67a4967b740acf2; https://git.kernel.org/stable/c/64ab50577c59bb7049bec6b5c42d1c38e4029f29