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

mtdchar: fix integer overflow in read/write ioctls

The "req.start" and "req.len" variables are u64 values that come from the
user at the start of the function.  We mask away the high 32 bits of
"req.len" so that's capped at U32_MAX but the "req.start" variable can go
up to U64_MAX which means that the addition can still integer overflow.

Use check_add_overflow() to fix this bug.
References: https://git.kernel.org/stable/c/37944f4f8199cd153fef74e95ca268020162f212; https://git.kernel.org/stable/c/457376c6fbf0c69326a9bf1f72416225f681192b; https://git.kernel.org/stable/c/e4185bed738da755b191aa3f2e16e8b48450e1b8
CVE: CVE-2025-68238
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mtd: rawnand: cadence: fix DMA device NULL pointer dereference

The DMA device pointer `dma_dev` was being dereferenced before ensuring
that `cdns_ctrl->dmac` is properly initialized.

Move the assignment of `dma_dev` after successfully acquiring the DMA
channel to ensure the pointer is valid before use.
References: https://git.kernel.org/stable/c/0c2a43cb43786011b48eeab6093db14888258c6b; https://git.kernel.org/stable/c/0c635241a62f2f5da1b48bfffae226d1f86a76ef; https://git.kernel.org/stable/c/2178b0255eae108bb10e5e99658b28641bc06f43
CVE: CVE-2025-68239
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

binfmt_misc: restore write access before closing files opened by open_exec()

bm_register_write() opens an executable file using open_exec(), which
internally calls do_open_execat() and denies write access on the file to
avoid modification while it is being executed.

However, when an error occurs, bm_register_write() closes the file using
filp_close() directly. This does not restore the write permission, which
may cause subsequent write operations on the same file to fail.

Fix this by calling exe_file_allow_write_access() before filp_close() to
restore the write permission properly.
References: https://git.kernel.org/stable/c/480ac88431703f2adbb8e6b5bd73c3f3cf9f3d7f; https://git.kernel.org/stable/c/6cce7bc7fac8471c832696720d9c8f2a976d9c54; https://git.kernel.org/stable/c/90f601b497d76f40fa66795c3ecf625b6aced9fd
CVE: CVE-2025-68240
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: avoid having an active sc_timer before freeing sci

Because kthread_stop did not stop sc_task properly and returned -EINTR,
the sc_timer was not properly closed, ultimately causing the problem [1]
reported by syzbot when freeing sci due to the sc_timer not being closed.

Because the thread sc_task main function nilfs_segctor_thread() returns 0
when it succeeds, when the return value of kthread_stop() is not 0 in
nilfs_segctor_destroy(), we believe that it has not properly closed
sc_timer.

We use timer_shutdown_sync() to sync wait for sc_timer to shutdown, and
set the value of sc_task to NULL under the protection of lock
sc_state_lock, so as to avoid the issue caused by sc_timer not being
properly shutdowned.

[1]
ODEBUG: free active (active state 0) object: 00000000dacb411a object type: timer_list hint: nilfs_construction_timeout
Call trace:
 nilfs_segctor_destroy fs/nilfs2/segment.c:2811 [inline]
 nilfs_detach_log_writer+0x668/0x8cc fs/nilfs2/segment.c:2877
 nilfs_put_super+0x4c/0x12c fs/nilfs2/super.c:509
References: https://git.kernel.org/stable/c/2f65799e2a736d556d306440c4e1e[PII_REDACTED]a; https://git.kernel.org/stable/c/36049e81dc7f077e0e24d5b9688a7458beacef8f; https://git.kernel.org/stable/c/9a6b60cb147d53968753a34805211d2e5e08c027
CVE: CVE-2025-68241
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe

The sit driver's packet transmission path calls: sit_tunnel_xmit() ->
update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called
to delete entries exceeding FNHE_RECLAIM_DEPTH+random.

The race window is between fnhe_remove_oldest() selecting fnheX for
deletion and the subsequent kfree_rcu(). During this time, the
concurrent path's __mkroute_output() -> find_exception() can fetch the
soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a
new dst using a dst_hold(). When the original fnheX is freed via RCU,
the dst reference remains permanently leaked.

CPU 0                             CPU 1
__mkroute_output()
  find_exception() [fnheX]
                                  update_or_create_fnhe()
                                    fnhe_remove_oldest() [fnheX]
  rt_bind_exception() [bind dst]
                                  RCU callback [fnheX freed, dst leak]

This issue manifests as a device reference count leak and a warning in
dmesg when unregistering the net device:

  unregister_netdevice: waiting for sitX to become free. Usage count = N

Ido Schimmel provided the simple test validation method [1].

The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().
Since rt_bind_exception() checks this field, setting it to zero prevents
the stale fnhe from being reused and bound to a new dst just before it
is freed.

[1]
ip netns add ns1
ip -n ns1 link set dev lo up
ip -n ns1 address add 192.0.2.1/32 dev lo
ip -n ns1 link add name dummy1 up type dummy
ip -n ns1 route add 192.0.2.2/32 dev dummy1
ip -n ns1 link add name gretap1 up arp off type gretap \
    local 192.0.2.1 remote 192.0.2.2
ip -n ns1 route add 198.51.0.0/16 dev gretap1
taskset -c 0 ip netns exec ns1 mausezahn gretap1 \
    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
taskset -c 2 ip netns exec ns1 mausezahn gretap1 \
    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &
sleep 10
ip netns pids ns1 | xargs kill
ip netns del ns1
References: https://git.kernel.org/stable/c/041ab9ca6e80d8f792bb69df28ebf1ef39c06af8; https://git.kernel.org/stable/c/0fd16ed6dc331636fb2a874c42d2f7d3156f7ff0; https://git.kernel.org/stable/c/298f1e0694ab4edb6092d66efed93c4554e6ced1
CVE: CVE-2025-68242
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix LTP test failures when timestamps are delegated

The utimes01 and utime06 tests fail when delegated timestamps are
enabled, specifically in subtests that modify the atime and mtime
fields using the 'nobody' user ID.

The problem can be reproduced as follow:

# echo "/media *(rw,no_root_squash,sync)" >> /etc/exports
# export -ra
# mount -o rw,nfsvers=4.2 127.0.0.1:/media /tmpdir
# cd /opt/ltp
# ./runltp -d /tmpdir -s utimes01
# ./runltp -d /tmpdir -s utime06

This issue occurs because nfs_setattr does not verify the inode's
UID against the caller's fsuid when delegated timestamps are
permitted for the inode.

This patch adds the UID check and if it does not match then the
request is sent to the server for permission checking.
References: https://git.kernel.org/stable/c/0e9be902041c6b9f0ed4b72764187eed1067a42f; https://git.kernel.org/stable/c/b2e4cda71ed062c87573b016d2d956a62f4258ed; https://git.kernel.org/stable/c/b623390045a81fc559decb9bfeb79319721d3dfb
CVE: CVE-2025-68243
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: Check the TLS certificate fields in nfs_match_client()

If the TLS security policy is of type RPC_XPRTSEC_TLS_X509, then the
cert_serial and privkey_serial fields need to match as well since they
define the client's identity, as presented to the server.
References: https://git.kernel.org/stable/c/b8fa[PII_REDACTED]1c04d4ecb742c73e2b296da6a8; https://git.kernel.org/stable/c/fb2cba0854a7f315c8100a807a6959b99d72479e
CVE: CVE-2025-68245
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: netpoll: fix incorrect refcount handling causing incorrect cleanup

commit efa95b01da18 ("netpoll: fix use after free") incorrectly
ignored the refcount and prematurely set dev->npinfo to NULL during
netpoll cleanup, leading to improper behavior and memory leaks.

Scenario causing lack of proper cleanup:

1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is
   allocated, and refcnt = 1
   - Keep in mind that npinfo is shared among all netpoll instances. In
     this case, there is just one.

2) Another netpoll is also associated with the same NIC and
   npinfo->refcnt += 1.
   - Now dev->npinfo->refcnt = 2;
   - There is just one npinfo associated to the netdev.

3) When the first netpolls goes to clean up:
   - The first cleanup succeeds and clears np->dev->npinfo, ignoring
     refcnt.
     - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);`
   - Set dev->npinfo = NULL, without proper cleanup
   - No ->ndo_netpoll_cleanup() is either called

4) Now the second target tries to clean up
   - The second cleanup fails because np->dev->npinfo is already NULL.
     * In this case, ops->ndo_netpoll_cleanup() was never called, and
       the skb pool is not cleaned as well (for the second netpoll
       instance)
  - This leaks npinfo and skbpool skbs, which is clearly reported by
    kmemleak.

Revert commit efa95b01da18 ("netpoll: fix use after free") and adds
clarifying comments emphasizing that npinfo cleanup should only happen
once the refcount reaches zero, ensuring stable and correct netpoll
behavior.
References: https://git.kernel.org/stable/c/49c8d2c1f94cc2f4d1a108530d7ba52614b874c2; https://git.kernel.org/stable/c/4afd4ebbad52aa146838ec23082ba393e426a2bb; https://git.kernel.org/stable/c/890472d6fbf062e6de7fdd56642cb305ab79d669
CVE: CVE-2025-68246
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: close accepted socket when per-IP limit rejects connection

When the per-IP connection limit is exceeded in ksmbd_kthread_fn(),
the code sets ret = -EAGAIN and continues the accept loop without
closing the just-accepted socket. That leaks one socket per rejected
attempt from a single IP and enables a trivial remote DoS.

Release client_sk before continuing.

This bug was found with ZeroPath.
References: https://git.kernel.org/stable/c/35521b5a7e8a184548125f[PII_REDACTED]236dcda1; https://git.kernel.org/stable/c/4587a7826be1ae0190dba10ff70b46bb0e3bc7d3; https://git.kernel.org/stable/c/5746b2a0f5eb3d79667b3c51fe849bd62464220e
CVE: CVE-2025-68247
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

posix-timers: Plug potential memory leak in do_timer_create()

When posix timer creation is set to allocate a given timer ID and the
access to the user space value faults, the function terminates without
freeing the already allocated posix timer structure.

Move the allocation after the user space access to cure that.

[ tglx: Massaged change log ]
References: https://git.kernel.org/stable/c/e0fd4d42e27f761e9cc82801b3f183e658dc749d; https://git.kernel.org/stable/c/f417f44524e7fc098e787c718d838b32723c0b2d
CVE: CVE-2025-68248
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

vmw_balloon: indicate success when effectively deflating during migration

When migrating a balloon page, we first deflate the old page to then
inflate the new page.

However, if inflating the new page succeeded, we effectively deflated the
old page, reducing the balloon size.

In that case, the migration actually worked: similar to migrating+
immediately deflating the new page.  The old page will be freed back to
the buddy.

Right now, the core will leave the page be marked as isolated (as we
returned an error).  When later trying to putback that page, we will run
into the WARN_ON_ONCE() in balloon_page_putback().

That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction:
stop using __ClearPageMovable()"); before that change, we would have
tolerated that way of handling it.

To fix it, let's just return 0 in that case, making the core effectively
just clear the "isolated" flag + freeing it back to the buddy as if the
migration succeeded.  Note that the new page will also get freed when the
core puts the last reference.

Note that this also makes it all be more consistent: we will no longer
unisolate the page in the balloon driver while keeping it marked as being
isolated in migration core.

This was found by code inspection.
References: https://git.kernel.org/stable/c/4ba5a8a7faa647ada8eae61a36517cf369f5bbe4; https://git.kernel.org/stable/c/aa05a044c5c2e147d726ac2fae1a97e0775eac11
CVE: CVE-2025-68249
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

most: usb: hdm_probe: Fix calling put_device() before device initialization

The early error path in hdm_probe() can jump to err_free_mdev before
&mdev->dev has been initialized with device_initialize(). Calling
put_device(&mdev->dev) there triggers a device core WARN and ends up
invoking kref_put(&kobj->kref, kobject_release) on an uninitialized
kobject.

In this path the private struct was only kmalloc'ed and the intended
release is effectively kfree(mdev) anyway, so free it directly instead
of calling put_device() on an uninitialized device.

This removes the WARNING and fixes the pre-initialization error path.
References: https://git.kernel.org/stable/c/3509c748e79435d09e730673c8c100b7f0ebc87c; https://git.kernel.org/stable/c/4af0eedbdb4df7936bf43a28e31af232744d2620; https://git.kernel.org/stable/c/6fb8fbc0aa542af5bf0fed94fa6b0edf18144f95
CVE: CVE-2025-68250
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

hung_task: fix warnings caused by unaligned lock pointers

The blocker tracking mechanism assumes that lock pointers are at least
4-byte aligned to use their lower bits for type encoding.

However, as reported by Eero Tamminen, some architectures like m68k
only guarantee 2-byte alignment of 32-bit values. This breaks the
assumption and causes two related WARN_ON_ONCE checks to trigger.

To fix this, the runtime checks are adjusted to silently ignore any lock
that is not 4-byte aligned, effectively disabling the feature in such
cases and avoiding the related warnings.

Thanks to Geert Uytterhoeven for bisecting!
References: https://git.kernel.org/stable/c/c0e2dcbe54cb15ecdf9d8f4501c[PII_REDACTED]888; https://git.kernel.org/stable/c/c97513cddcfc235f[PII_REDACTED]838e500af21d01
CVE: CVE-2025-68251
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: avoid infinite loops due to corrupted subpage compact indexes

Robert reported an infinite loop observed by two crafted images.

The root cause is that `clusterofs` can be larger than `lclustersize`
for !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:

  blocksize = lclustersize = 512   lcn = 6   clusterofs = 515

Move the corresponding check for full compress indexes to
`z_erofs_load_lcluster_from_disk()` to also cover subpage compact
compress indexes.

It also fixes the position of `m->type >= Z_EROFS_LCLUSTER_TYPE_MAX`
check, since it should be placed right after
`z_erofs_load_{compact,full}_lcluster()`.
References: https://git.kernel.org/stable/c/8675447a8794983f2b7e694b378112772c17635e; https://git.kernel.org/stable/c/e13d315ae077bb7c3c6027cc292401bc0f4ec683
CVE: CVE-2025-68252
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup

In fastrpc_map_lookup, dma_buf_get is called to obtain a reference to
the dma_buf for comparison purposes. However, this reference is never
released when the function returns, leading to a dma_buf memory leak.

Fix this by adding dma_buf_put before returning from the function,
ensuring that the temporarily acquired reference is properly released
regardless of whether a matching map is found.

Rule: add
References: https://git.kernel.org/stable/c/214e81a63a9aa0be42382ef0365ba5ed32c513ab; https://git.kernel.org/stable/c/9a297a68c3ba4a7ecb31ed52f61bd6634abb79d3; https://git.kernel.org/stable/c/c2fef5ebb73f3dabae6fbc571d181914ed32c483
CVE: CVE-2025-68253
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: don't spin in add_stack_record when gfp flags don't allow

syzbot was able to find the following path:
  add_stack_record_to_list mm/page_owner.c:182 [inline]
  inc_stack_record_count mm/page_owner.c:214 [inline]
  __set_page_owner+0x2c3/0x4a0 mm/page_owner.c:333
  set_page_owner include/linux/page_owner.h:32 [inline]
  post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851
  prep_new_page mm/page_alloc.c:1859 [inline]
  get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858
  alloc_pages_nolock_noprof+0x94/0x120 mm/page_alloc.c:7554

Don't spin in add_stack_record_to_list() when it is called
from *_nolock() context.
References: https://git.kernel.org/stable/c/[PII_REDACTED]53e3af73e626e328603d7eb5986f34; https://git.kernel.org/stable/c/c83aab85e18103a6dc066b4939e2c92a02bb1b05
CVE: CVE-2025-68254
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8723bs: fix out-of-bounds read in OnBeacon ESR IE parsing

The Extended Supported Rates (ESR) IE handling in OnBeacon accessed
*(p + 1 + ielen) and *(p + 2 + ielen) without verifying that these
offsets lie within the received frame buffer. A malformed beacon with
an ESR IE positioned at the end of the buffer could cause an
out-of-bounds read, potentially triggering a kernel panic.

Add a boundary check to ensure that the ESR IE body and the subsequent
bytes are within the limits of the frame before attempting to access
them.

This prevents OOB reads caused by malformed beacon frames.
References: https://git.kernel.org/stable/c/38292407c2bb5b2b3131aaace4ecc7a829b40b76; https://git.kernel.org/stable/c/502ddcc405b69fa92e0add6c1714d654504f6fd7; https://git.kernel.org/stable/c/bb5940193d813449540d8d3a82abc045be41f48a
CVE: CVE-2025-68255
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsing

The Supported Rates IE length from an incoming Association Request frame
was used directly as the memcpy() length when copying into a fixed-size
16-byte stack buffer (supportRate). A malicious station can advertise an
IE length larger than 16 bytes, causing a stack buffer overflow.

Clamp ie_len to the buffer size before copying the Supported Rates IE,
and correct the bounds check when merging Extended Supported Rates to
prevent a second potential overflow.

This prevents kernel stack corruption triggered by malformed association
requests.
References: https://git.kernel.org/stable/c/25411f5fcf[PII_REDACTED]f337c99c2bbf3f8477f5; https://git.kernel.org/stable/c/34620eb602aa432f090b2b784ee5c5070fb16cf9; https://git.kernel.org/stable/c/4445adedae[PII_REDACTED]03d1ce41f9e88a1944b6
CVE: CVE-2025-68256
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8723bs: fix out-of-bounds read in rtw_get_ie() parser

The Information Element (IE) parser rtw_get_ie() trusted the length
byte of each IE without validating that the IE body (len bytes after
the 2-byte header) fits inside the remaining frame buffer. A malformed
frame can advertise an IE length larger than the available data, causing
the parser to increment its pointer beyond the buffer end. This results
in out-of-bounds reads or, depending on the pattern, an infinite loop.

Fix by validating that (offset + 2 + len) does not exceed the limit
before accepting the IE or advancing to the next element.

This prevents OOB reads and ensures the parser terminates safely on
malformed frames.
References: https://git.kernel.org/stable/c/154828bf9559b9c8421fc2f0d7f7f76b3683aaed; https://git.kernel.org/stable/c/30c558447e90935f0de61be181bbcedf75952e00; https://git.kernel.org/stable/c/9829c6e1b2e4180fd18315252ad6faeab6128076
CVE: CVE-2025-68257
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: check device's attached status in compat ioctls

Syzbot identified an issue [1] that crashes kernel, seemingly due to
unexistent callback dev->get_valid_routes(). By all means, this should
not occur as said callback must always be set to
get_zero_valid_routes() in __comedi_device_postconfig().

As the crash seems to appear exclusively in i386 kernels, at least,
judging from [1] reports, the blame lies with compat versions
of standard IOCTL handlers. Several of them are modified and
do not use comedi_unlocked_ioctl(). While functionality of these
ioctls essentially copy their original versions, they do not
have required sanity check for device's attached status. This,
in turn, leads to a possibility of calling select IOCTLs on a
device that has not been properly setup, even via COMEDI_DEVCONFIG.

Doing so on unconfigured devices means that several crucial steps
are missed, for instance, specifying dev->get_valid_routes()
callback.

Fix this somewhat crudely by ensuring device's attached status before
performing any ioctls, improving logic consistency between modern
and compat functions.

[1] Syzbot report:
BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
...
CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4:[PII_REDACTED]352ef0
Call Trace:
 <TASK>
 get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline]
 parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401
 do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594
 compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline]
 comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273
 __do_compat_sys_ioctl fs/ioctl.c:695 [inline]
 __se_compat_sys_ioctl fs/ioctl.c:638 [inline]
 __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
...
References: https://git.kernel.org/stable/c/0de7d9cd07a2671fa6089173bccc0b2afe6b93ee; https://git.kernel.org/stable/c/4836ba483a22ebd076c8faaf8293a7295fad4142; https://git.kernel.org/stable/c/573b07d2e3d473ee7eb625ef87519922cf01168d
CVE: CVE-2025-68258
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: multiq3: sanitize config options in multiq3_attach()

Syzbot identified an issue [1] in multiq3_attach() that induces a
task timeout due to open() or COMEDI_DEVCONFIG ioctl operations,
specifically, in the case of multiq3 driver.

This problem arose when syzkaller managed to craft weird configuration
options used to specify the number of channels in encoder subdevice.
If a particularly great number is passed to s->n_chan in
multiq3_attach() via it->options[2], then multiple calls to
multiq3_encoder_reset() at the end of driver-specific attach() method
will be running for minutes, thus blocking tasks and affected devices
as well.

While this issue is most likely not too dangerous for real-life
devices, it still makes sense to sanitize configuration inputs. Enable
a sensible limit on the number of encoder chips (4 chips max, each
with 2 channels) to stop this behaviour from manifesting.

[1] Syzbot crash:
INFO: task syz.2.19:6067 blocked for more than 143 seconds.
...
Call Trace:
 <TASK>
 context_switch kernel/sched/core.c:5254 [inline]
 __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862
 __schedule_loop kernel/sched/core.c:6944 [inline]
 schedule+0x165/0x360 kernel/sched/core.c:6959
 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016
 __mutex_lock_common kernel/locking/mutex.c:676 [inline]
 __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760
 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868
 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414
 do_dentry_open+0x953/0x13f0 fs/open.c:965
 vfs_open+0x3b/0x340 fs/open.c:1097
...
References: https://git.kernel.org/stable/c/049f[PII_REDACTED]750f929ebfff36d849511e132; https://git.kernel.org/stable/c/4cde9a7e025cc09b88097c70606f6b30c22880f4; https://git.kernel.org/stable/c/543f4c380c2e1f35e60528df7cb54705cda7fee3