CVE-2025-21944

ksmbd: fix bug on trap in smb2_lock

5.5 MediumFix available

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix bug on trap in smb2_lock

If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.

Attack profile

How easy it is to exploit

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: None
Integrity: None
Availability: High

Exploit likelihood

0.16%Up 0.1 points since Apr 2, 2025

What each source reports

NVD Score used 5.5

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix bug on trap in smb2_lock

If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.

Record: CVE-2025-21944
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-667
Updated: 2026-11-02

CVE List No score

ksmbd: fix bug on trap in smb2_lock

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix bug on trap in smb2_lock

If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.

Record: CVE-2025-21944
Updated: 2026-11-02

EUVDEUVD-2025-9377 No score

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix bug on trap in smb2_lock

If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.

Record: EUVD-2025-9377
Updated: 2026-11-02

GitHub AdvisoriesGHSA-q86w-66m5-qpj3 5.5

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix bug on trap in...

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix bug on trap in smb2_lock

If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.

Record: GHSA-q86w-66m5-qpj3
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness: CWE-667
Updated: 2026-11-02

OSVBELL-CVE-2025-21944 5.5

Record: BELL-CVE-2025-21944
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVDEBIAN-CVE-2025-21944 5.5

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix bug on trap in smb2_lock If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.

Record: DEBIAN-CVE-2025-21944
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

Show 24 moreShow less

OSVOESA-2025-1729 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()irq_find_at_or_after() dereferences the interrupt descriptor which isreturned by mt_find() while neither holding sparse_irq_lock nor RCU readlock, which means the descriptor can be freed between mt_find() and thedereference: CPU0 CPU1 desc = mt_find() delayed_free_desc(desc) irq_desc_get_irq(desc)The use-after-free is reported by KASAN: Call trace: irq_get_next_irq+0x58/0x84 show_stat+0x638/0x824 seq_read_iter+0x158/0x4ec proc_reg_read_iter+0x94/0x12c vfs_read+0x1e0/0x2c8 Freed by task 4471: slab_free_freelist_hook+0x174/0x1e0 __kmem_cache_free+0xa4/0x1dc kfree+0x64/0x128 irq_kobj_release+0x28/0x3c kobject_put+0xcc/0x1e0 delayed_free_desc+0x14/0x2c rcu_do_batch+0x214/0x720Guard the access with a RCU read lock section.(CVE-2024-38385)

In the Linux kernel, the following vulnerability has been resolved:

drm/lima: fix shared irq handling on driver remove

lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.(CVE-2024-42127)

In the Linux kernel, the following vulnerability has been resolved:mm: avoid overflows in dirty throttling logicThe dirty throttling logic is interspersed with assumptions that dirtylimits in PAGE_SIZE units fit into 32-bit (so that various multiplicationsfit into 64-bits). If limits end up being larger, we will hit overflows,possible divisions by 0 etc. Fix these problems by never allowing solarge dirty limits as they have dubious practical value anyway. Fordirty_bytes / dirty_background_bytes interfaces we can just refuse to setso large limits. For dirty_ratio / dirty_background_ratio it isn t sosimple as the dirty limit is computed from the amount of available memorywhich can change due to memory hotplug etc. So when converting dirtylimits from ratios to numbers of pages, we just don t allow the result toexceed UINT_MAX.This is root-only triggerable problem which occurs when the operatorsets dirty limits to >16 TB.(CVE-2024-42131)

In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()

For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set().

This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call.

Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state.

Patchwork: https://patchwork.freedesktop.org/patch/606729/(CVE-2024-45015)

In the Linux kernel, the following vulnerability has been resolved:

crypto: iaa - Fix potential use after free bug

The free_device_compression_mode(iaa_device, device_mode) function frees "device_mode" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free.

The good news is that, so far as I can tell, nothing implements the ->free()…

Record: OESA-2025-1729
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-1730 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

crypto: iaa - Fix potential use after free bug

The free_device_compression_mode(iaa_device, device_mode) function frees "device_mode" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free.

The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)(CVE-2024-47732)

In the Linux kernel, the following vulnerability has been resolved:

tomoyo: don't emit warning in tomoyo_write_control()

syzbot is reporting too large allocation warning at tomoyo_write_control(), for one can write a very very long line without new line character. To fix this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies.

One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.(CVE-2024-58085)

In the Linux kernel, the following vulnerability has been resolved:

sockmap, vsock: For connectible sockets allow only connected

sockmap expects all vsocks to have a transport assigned, which is expressed in vsock_proto::psock_update_sk_prot(). However, there is an edge case where an unconnected (connectible) socket may lose its previously assigned transport. This is handled with a NULL check in the vsock/BPF recv path.

Another design detail is that listening vsocks are not supposed to have any transport assigned at all. Which implies they are not supported by the sockmap. But this is complicated by the fact that a socket, before switching to TCP_LISTEN, may have had some transport assigned during a failed connect() attempt. Hence, we may end up with a listening vsock in a sockmap, which blows up quickly:

KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127] CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+ Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:vsock_read_skb+0x4b/0x90 Call Trace: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2acc vsock_loopback_work+0x27d/0x3f0 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x35a/0x700 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30

For connectible sockets, instead of relying solely on the state of vsk->transport, tell sockmap to only allow those representing established connections. This aligns with the behaviour for AF_INET and AF_UNIX.(CVE-2025-21854)

In the Linux kernel, the following vulnerability has been resolved:

mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()

If migration succeeded, we called folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0.

Similarly, if migration failed, memcg_data of the dst folio is left unset.

If we call folio_putback_lru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:

./hmm-tests

...

RUN hmm.hmm_device_private.migrate ...

[ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000…

Record: OESA-2025-1730
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVROOT-OS-UBUNTU-2204-CVE-2025-21944 5.5

CVE-2025-21944 in linux - Patched by Root

Root has patched CVE-2025-21944 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2204-CVE-2025-21944
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-06

OSVROOT-OS-UBUNTU-2404-CVE-2025-21944 5.5

CVE-2025-21944 in linux - Patched by Root

Root has patched CVE-2025-21944 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2404-CVE-2025-21944
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-06

OSVUBUNTU-CVE-2025-21944 7.1

Record: UBUNTU-CVE-2025-21944
CVSS 4.0: 7.1 HighCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
CVSS 3.1: 5.5 MediumCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-11

OSV No score

ksmbd: fix bug on trap in smb2_lock

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix bug on trap in smb2_lock

If lock count is greater than 1, flags could be old value. It should be checked with flags of smb_lock, not flags. It will cause bug-on trap from locks_free_lock in error handling routine.

Record: CVE-2025-21944
Updated: 2026-11-02

OSVUSN-7605-1 No score

linux, linux-aws, linux-gcp, linux-gcp-6.11, linux-hwe-6.11, linux-oracle, linux-raspi, linux-realtime vulnerabilities

It was discovered that the CIFS network file system implementation in the Linux kernel did not properly verify the target namespace when handling upcalls. An attacker could use this to expose sensitive information. (CVE-2025-2312)