deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-21745
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: Fix class @block_class's subsystem refcount leakage

blkcg_fill_root_iostats() iterates over @block_class's devices by
class_dev_iter_(init|next)(), but does not end iterating with
class_dev_iter_exit(), so causes the class's subsystem refcount leakage.

Fix by ending the iterating with class_dev_iter_exit().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2ce09aabe009453d641a2ceb79e6461a2d4f3876; https://git.kernel.org/stable/c/38287f779b34dfe959b4b681e909f2d3d52b88be; https://git.kernel.org/stable/c/431b6ef2714be4d5babb[PII_REDACTED]41a88b43b0
CVE: CVE-2025-21746
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: synaptics - fix crash when enabling pass-through port

When enabling a pass-through port an interrupt might come before psmouse
driver binds to the pass-through port. However synaptics sub-driver
tries to access psmouse instance presumably associated with the
pass-through port to figure out if only 1 byte of response or entire
protocol packet needs to be forwarded to the pass-through port and may
crash if psmouse instance has not been attached to the port yet.

Fix the crash by introducing open() and close() methods for the port and
check if the port is open before trying to access psmouse instance.
Because psmouse calls serio_open() only after attaching psmouse instance
to serio port instance this prevents the potential crash.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-367
References: https://git.kernel.org/stable/c/08bd5b7c9a2401faabdaa1472d45c7de0755fd7e; https://git.kernel.org/stable/c/3e179d3f1ada963475395d81bfe91daef4d1a24c; https://git.kernel.org/stable/c/87da1ea93ec9f9f0004e5b12e78789bc94e360bf
CVE: CVE-2025-21747
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/ast: astdp: Fix timeout for enabling video signal

The ASTDP transmitter sometimes takes up to 1 second for enabling the
video signal, while the timeout is only 200 msec. This results in a
kernel error message. Increase the timeout to 1 second. An example
of the error message is shown below.

[  697.084433] ------------[ cut here ]------------
[  697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled))
[  697.091233] WARNING: CPU: 1 PID: 160 at drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast]
[...]
[  697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast]
[...]
[  697.415283] Call Trace:
[  697.420727]  <TASK>
[  697.425908]  ? show_trace_log_lvl+0x196/0x2c0
[  697.433304]  ? show_trace_log_lvl+0x196/0x2c0
[  697.440693]  ? drm_atomic_helper_commit_modeset_enables+0x30a/0x470
[  697.450115]  ? ast_dp_set_enable+0x123/0x140 [ast]
[  697.458059]  ? __warn.cold+0xaf/0xca
[  697.464713]  ? ast_dp_set_enable+0x123/0x140 [ast]
[  697.472633]  ? report_bug+0x134/0x1d0
[  697.479544]  ? handle_bug+0x58/0x90
[  697.486127]  ? exc_invalid_op+0x13/0x40
[  697.492975]  ? asm_exc_invalid_op+0x16/0x20
[  697.500224]  ? preempt_count_sub+0x14/0xc0
[  697.507473]  ? ast_dp_set_enable+0x123/0x140 [ast]
[  697.515377]  ? ast_dp_set_enable+0x123/0x140 [ast]
[  697.523227]  drm_atomic_helper_commit_modeset_enables+0x30a/0x470
[  697.532388]  drm_atomic_helper_commit_tail+0x58/0x90
[  697.540400]  ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast]
[  697.550009]  commit_tail+0xfe/0x1d0
[  697.556547]  drm_atomic_helper_commit+0x198/0x1c0

This is a cosmetical problem. Enabling the video signal still works
even with the error message. The problem has always been present, but
only recent versions of the ast driver warn about missing the timeout.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]31cce220c9cab9f27cb[PII_REDACTED]e; https://git.kernel.org/stable/c/fd39c41bcd82d5ebaaebadb944eab5598c668a90
CVE: CVE-2025-21748
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix integer overflows on 32 bit systems

On 32bit systems the addition operations in ipc_msg_alloc() can
potentially overflow leading to memory corruption.
Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/760568c1f62ea874e8fb492f9cfa4f47b4b8391e; https://git.kernel.org/stable/c/82f59d64e6297f270311b16b5dcf65be406d1ea3; https://git.kernel.org/stable/c/aab98e2dbd648510f8f51b83fbf4721206ccae45
CVE: CVE-2025-21749
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: rose: lock the socket in rose_bind()

syzbot reported a soft lockup in rose_loopback_timer(),
with a repro calling bind() from multiple threads.

rose_bind() must lock the socket to avoid this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/4c04b0ab3a647e76d0e752b013de8e404abafc63; https://git.kernel.org/stable/c/667f61b3498df751c8b3f0be1637e7226cbe3ed0; https://git.kernel.org/stable/c/970cd2ed26cdab2b0f15b6d90d7eaa36538244a5
CVE: CVE-2025-21750
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: Check the return value of of_property_read_string_index()

Somewhen between 6.10 and 6.11 the driver started to crash on my
MacBookPro14,3. The property doesn't exist and 'tmp' remains
uninitialized, so we pass a random pointer to devm_kstrdup().

The crash I am getting looks like this:

BUG: unable to handle page fault for address: 00007f033c669379
PF: supervisor read access in kernel mode
PF: error_code(0x0001) - permissions violation
PGD [PII_REDACTED] P4D [PII_REDACTED] PUD 101340067 PMD 1013bb067 PTE 800000010aee9025
Oops: Oops: 0001 [#1] SMP PTI
CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1
Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024
RIP: 0010:strlen+0x4/0x30
Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc
RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202
RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: [PII_REDACTED]
RDX:[PII_REDACTED]000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379
RBP: 00000000ffffffea R08: [PII_REDACTED] R09: 00000000c0ba916a
R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8
R13:[PII_REDACTED]000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30
FS:  00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007f033c669379 CR3:[PII_REDACTED]b1e004 CR4:[PII_REDACTED]3706f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 ? __die+0x23/0x70
 ? page_fault_oops+0x149/0x4c0
 ? raw_spin_rq_lock_nested+0xe/0x20
 ? sched_balance_newidle+0x22b/0x3c0
 ? update_load_avg+0x78/0x770
 ? exc_page_fault+0x6f/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? __pfx_pci_conf1_write+0x10/0x10
 ? strlen+0x4/0x30
 devm_kstrdup+0x25/0x70
 brcmf_of_probe+0x273/0x350 [brcmfmac]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/082d9e263af8de68f0c34f67b[PII_REDACTED]60f6e; https://git.kernel.org/stable/c/7ef2ea1429684d5cef207519bdf6ce45e50e8ac5; https://git.kernel.org/stable/c/af525a8b2ab85291617e79a5bb18bcdcb529e80c
CVE: CVE-2025-21751
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: HWS, change error flow on matcher disconnect

Currently, when firmware failure occurs during matcher disconnect flow,
the error flow of the function reconnects the matcher back and returns
an error, which continues running the calling function and eventually
frees the matcher that is being disconnected.
This leads to a case where we have a freed matcher on the matchers list,
which in turn leads to use-after-free and eventual crash.

This patch fixes that by not trying to reconnect the matcher back when
some FW command fails during disconnect.

Note that we're dealing here with FW error. We can't overcome this
problem. This might lead to bad steering state (e.g. wrong connection
between matchers), and will also lead to resource leakage, as it is
the case with any other error handling during resource destruction.

However, the goal here is to allow the driver to continue and not crash
the machine with use-after-free error.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1ce840c7a659aa53a31ef49f0271b4fd0dc10296; https://git.kernel.org/stable/c/23a86c76a1a197e8fbbbd0ce3e826eb58c471624; https://git.kernel.org/stable/c/5682aad0276ff9b9b0eff3188eb6a1f504d6b436
CVE: CVE-2025-21755
Published: 2025-02-27
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-21756
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

vsock: Keep the binding until socket destruction

Preserve sockets bindings; this includes both resulting from an explicit
bind() and those implicitly bound through autobind during connect().

Prevents socket unbinding during a transport reassignment, which fixes a
use-after-free:

    1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
    2. transport->release() calls vsock_remove_bound() without checking if
       sk was bound and moved to bound list (refcnt=1)
    3. vsock_bind() assumes sk is in unbound list and before
       __vsock_insert_bound(vsock_bound_sockets()) calls
       __vsock_remove_bound() which does:
           list_del_init(&vsk->bound_table); // nop
           sock_put(&vsk->sk);               // refcnt=0

BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730
Read of size 4 at addr ffff88816b46a74c by task a.out/2057
 dump_stack_lvl+0x68/0x90
 print_report+0x174/0x4f6
 kasan_report+0xb9/0x190
 __vsock_bind+0x62e/0x730
 vsock_bind+0x97/0xe0
 __sys_bind+0x154/0x1f0
 __x64_sys_bind+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Allocated by task 2057:
 kasan_save_stack+0x1e/0x40
 kasan_save_track+0x10/0x30
 __kasan_slab_alloc+0x85/0x90
 kmem_cache_alloc_noprof+0x131/0x450
 sk_prot_alloc+0x5b/0x220
 sk_alloc+0x2c/0x870
 __vsock_create.constprop.0+0x2e/0xb60
 vsock_create+0xe4/0x420
 __sock_create+0x241/0x650
 __sys_socket+0xf2/0x1a0
 __x64_sys_socket+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Freed by task 2057:
 kasan_save_stack+0x1e/0x40
 kasan_save_track+0x10/0x30
 kasan_save_free_info+0x37/0x60
 __kasan_slab_free+0x4b/0x70
 kmem_cache_free+0x1a1/0x590
 __sk_destruct+0x388/0x5a0
 __vsock_bind+0x5e1/0x730
 vsock_bind+0x97/0xe0
 __sys_bind+0x154/0x1f0
 __x64_sys_bind+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

refcount_t: addition on 0; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150
RIP: 0010:refcount_warn_saturate+0xce/0x150
 __vsock_bind+0x66d/0x730
 vsock_bind+0x97/0xe0
 __sys_bind+0x154/0x1f0
 __x64_sys_bind+0x6e/0xb0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

refcount_t: underflow; use-after-free.
WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150
RIP: 0010:refcount_warn_saturate+0xee/0x150
 vsock_remove_bound+0x187/0x1e0
 __vsock_release+0x383/0x4a0
 vsock_release+0x90/0x120
 __sock_release+0xa3/0x250
 sock_close+0x14/0x20
 __fput+0x359/0xa80
 task_work_run+0x107/0x1d0
 do_exit+0x847/0x2560
 do_group_exit+0xb8/0x250
 __x64_sys_exit_group+0x3a/0x50
 x64_sys_call+0xfec/0x14f0
 do_syscall_64+0x93/0x1b0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3f[PII_REDACTED]8951cc1be7ab1ce6b7f05c670d8b; https://git.kernel.org/stable/c/42b33381e5e1f2b967dc4fb4221ddb9aaf10d197; https://git.kernel.org/stable/c/645ce25aa0e67895b11d89f27bb86c9d444c40f8
CVE: CVE-2025-21757
Published: 2025-02-27
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-21758
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: mcast: add RCU protection to mld_newpack()

mld_newpack() can be called without RTNL or RCU being held.

Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.

Instead use alloc_skb() and charge the net->ipv6.igmp_sk
socket under RCU protection.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1b91c597b0214b1b462eb627ec02658c944623f2; https://git.kernel.org/stable/c/25195f9d5ffcc8079ad743a50c0409dbdc48d98a; https://git.kernel.org/stable/c/29fa42197f26a97cde29fa8c40beddf44ea5c8f3
CVE: CVE-2025-21759
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: mcast: extend RCU protection in igmp6_send()

igmp6_send() can be called without RTNL or RCU being held.

Extend RCU protection so that we can safely fetch the net pointer
and avoid a potential UAF.

Note that we no longer can use sock_alloc_send_skb() because
ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.

Instead use alloc_skb() and charge the net->ipv6.igmp_sk
socket under RCU protection.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/087c1faa594fa07a66933d750c0b2610aa1a2946; https://git.kernel.org/stable/c/0bf8e2f3768629d437a32cb824149e6e98254381; https://git.kernel.org/stable/c/81b25a07ebf53f9ef4ca8f3d96a8ddb94561dd5a
CVE: CVE-2025-21760
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ndisc: extend RCU protection in ndisc_send_skb()

ndisc_send_skb() can be called without RTNL or RCU held.

Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()
and avoid a potential UAF.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/04e05112f10354ffc3bb6cc796d553bab161594c; https://git.kernel.org/stable/c/10a1f3fece2f0d23a3a618b72b2b4e6f408ef7d1; https://git.kernel.org/stable/c/4d576202b90b1b95a7c428a80b536f91b8201bcc
CVE: CVE-2025-21761
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

openvswitch: use RCU protection in ovs_vport_cmd_fill_info()

ovs_vport_cmd_fill_info() can be called without RTNL or RCU.

Use RCU protection and dev_net_rcu() to avoid potential UAF.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/[PII_REDACTED]af[PII_REDACTED]5d657095d95c53dbd0; https://git.kernel.org/stable/c/7e01abc34e87abd091e619161a20f54ed4e3e2da; https://git.kernel.org/stable/c/8ec57509c36c8b9a23e50b7858dda0c520a2d074
CVE: CVE-2025-21762
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

arp: use RCU protection in arp_xmit()

arp_xmit() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/01d1b5c9abcaff29a43f1d17a19c33eec92c7dbe; https://git.kernel.org/stable/c/10f555e3f573d004ae9d89b3276abb58c4ede5c3; https://git.kernel.org/stable/c/2c331718d3389b6c5f6855078ab7171849e016bd
CVE: CVE-2025-21763
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

neighbour: use RCU protection in __neigh_notify()

__neigh_notify() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1cbb2aa90cd3fba15ad7efb5cdda28f3d1082379; https://git.kernel.org/stable/c/40d8f2f2a373b6c294ffac394d2bb814b572ead1; https://git.kernel.org/stable/c/559307d25235e24b5424778c7332451b6c741159
CVE: CVE-2025-21764
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ndisc: use RCU protection in ndisc_alloc_skb()

ndisc_alloc_skb() can be called without RTNL or RCU being held.

Add RCU protection to avoid possible UAF.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3c2d705f5adf5d860aaef90cb4211c0fde2ba66d; https://git.kernel.org/stable/c/628e6d18930bbd21f2d4562228afe27694f66da9; https://git.kernel.org/stable/c/96fc896d0e5b37c12808df797397fb16f3080879
CVE: CVE-2025-21765
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: use RCU protection in ip6_default_advmss()

ip6_default_advmss() needs rcu protection to make
sure the net structure it reads does not disappear.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/28de355b63ad42309ed5a03ee7c436c90512265b; https://git.kernel.org/stable/c/3c8ffcd248da34fc41e52a46e[PII_REDACTED]5fc2a; https://git.kernel.org/stable/c/4176a68b0db8fc74ac14fcd00ba[PII_REDACTED]dc2
CVE: CVE-2025-21766
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv4: use RCU protection in __ip_rt_update_pmtu()

__ip_rt_update_pmtu() must use RCU protection to make
sure the net structure it reads does not disappear.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/139512191bd06f1b496117c76372b2ce372c9a41; https://git.kernel.org/stable/c/4583748b65dee4d61bd50a2214715b4237bc152a; https://git.kernel.org/stable/c/9b1766d1ff5fe496aabe9fc5f4e34e53f35c11c4
CVE: CVE-2025-21767
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context

The following bug report happened with a PREEMPT_RT kernel:

  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog
  preempt_count: 1, expected: 0
  RCU nest depth: 0, expected: 0
  get_random_u32+0x4f/0x110
  clocksource_verify_choose_cpus+0xab/0x1a0
  clocksource_verify_percpu.part.0+0x6b/0x330
  clocksource_watchdog_kthread+0x193/0x1a0

It is due to the fact that clocksource_verify_choose_cpus() is invoked with
preemption disabled.  This function invokes get_random_u32() to obtain
random numbers for choosing CPUs.  The batched_entropy_32 local lock and/or
the base_crng.lock spinlock in driver/char/random.c will be acquired during
the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot
be acquired in atomic context.

Fix this problem by using migrate_disable() to allow smp_processor_id() to
be reliably used without introducing atomic context. preempt_disable() is
then called after clocksource_verify_choose_cpus() but before the
clocksource measurement is being run to avoid introducing unexpected
latency.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0fb534187d2355f6c8f995321e76d1ccd1262ac1; https://git.kernel.org/stable/c/60f54f0d4ea530950549a8263e6fdd70a40490a4; https://git.kernel.org/stable/c/6bb05a33337b2c842373857b63de5c9bf1ae2a09
CVE: CVE-2025-21768
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels

Some lwtunnels have a dst cache for post-transformation dst.
If the packet destination did not change we may end up recording
a reference to the lwtunnel in its own cache, and the lwtunnel
state will never be freed.

Discovered by the ioam6.sh test, kmemleak was recently fixed
to catch per-cpu memory leaks. I'm not sure if rpl and seg6
can actually hit this, but in principle I don't see why not.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/4c0f200c7d06fedddde82209c099014d63f4a6c0; https://git.kernel.org/stable/c/5ab11a4e219e93b8b31a27f8ec98d42afadd8b7a; https://git.kernel.org/stable/c/92191dd[PII_REDACTED]21b862b791dcc83e558e07
CVE: CVE-2025-21769
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: vmclock: Add .owner to vmclock_miscdev_fops

Without the .owner field, the module can be unloaded while /dev/vmclock0
is open, leading to an oops.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3b5709225b43ee33e1026dd1fc0949a7f19b5289; https://git.kernel.org/stable/c/7b07b040257c1b658ef3eca86e4b6ae02d65069c
CVE: CVE-2025-21770
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu: Fix potential memory leak in iopf_queue_remove_device()

The iopf_queue_remove_device() helper removes a device from the per-iommu
iopf queue when PRI is disabled on the device. It responds to all
outstanding iopf's with an IOMMU_PAGE_RESP_INVALID code and detaches the
device from the queue.

However, it fails to release the group structure that represents a group
of iopf's awaiting for a response after responding to the hardware. This
can cause a memory leak if iopf_queue_remove_device() is called with
pending iopf's.

Fix it by calling iopf_free_group() after the iopf group is responded.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/90d5429cd2921ca2714684ed525898d431bb9283; https://git.kernel.org/stable/c/9759ae2cee7cd42b95f1c48aa3749bd02b5ddb08; https://git.kernel.org/stable/c/db60d2d896a17decd58d143eef92cf22eb0a0176
CVE: CVE-2025-21771
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Fix incorrect autogroup migration detection

scx_move_task() is called from sched_move_task() and tells the BPF scheduler
that cgroup migration is being committed. sched_move_task() is used by both
cgroup and autogroup migrations and scx_move_task() tried to filter out
autogroup migrations by testing the destination cgroup and PF_EXITING but
this is not enough. In fact, without explicitly tagging the thread which is
doing the cgroup migration, there is no good way to tell apart
scx_move_task() invocations for racing migration to the root cgroup and an
autogroup migration.

This led to scx_move_task() incorrectly ignoring a migration from non-root
cgroup to an autogroup of the root cgroup triggering the following warning:

  WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340
  ...
  Call Trace:
  <TASK>
    cgroup_migrate_execute+0x5b1/0x700
    cgroup_attach_task+0x296/0x400
    __cgroup_procs_write+0x128/0x140
    cgroup_procs_write+0x17/0x30
    kernfs_fop_write_iter+0x141/0x1f0
    vfs_write+0x31d/0x4a0
    __x64_sys_write+0x72/0xf0
    do_syscall_64+0x82/0x160
    entry_SYSCALL_64_after_hwframe+0x76/0x7e

Fix it by adding an argument to sched_move_task() that indicates whether the
moving is for a cgroup or autogroup migration. After the change,
scx_move_task() is called only for cgroup migrations and renamed to
scx_cgroup_move_task().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/75bf2f80c046d2ec5a07455891ea0a9fb6d8b5f6; https://git.kernel.org/stable/c/d6f3e7d564b2309e1f17e709a70eca78d7ca2bb8; https://git.kernel.org/stable/c/d8b510d0ddc65d8a71e0f9a3acc9ed5f010fc514