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

memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()

As of_find_node_by_name() release the reference of the argument device
node, tegra_emc_find_node_by_ram_code() releases some device nodes while
still in use, resulting in possible UAFs. According to the bindings and
the in-tree DTS files, the "emc-tables" node is always device's child
node with the property "nvidia,use-ram-code", and the "lpddr2" node is a
child of the "emc-tables" node. Thus utilize the
for_each_child_of_node() macro and of_get_child_by_name() instead of
of_find_node_by_name() to simplify the code.

This bug was found by an experimental verification tool that I am
developing.

[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3b02273446e23961d910b50cc12528faec649fb2; https://git.kernel.org/stable/c/755e44538c190c31de9090d8e8821d228fcfd416; https://git.kernel.org/stable/c/b9784e5cde1f9fb83661a70e580e381ae1264d12
CVE: CVE-2024-58042
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

rhashtable: Fix potential deadlock by moving schedule_work outside lock

Move the hash table growth check and work scheduling outside the
rht lock to prevent a possible circular locking dependency.

The original implementation could trigger a lockdep warning due to
a potential deadlock scenario involving nested locks between
rhashtable bucket, rq lock, and dsq lock. By relocating the
growth check and work scheduling after releasing the rth lock, we break
this potential deadlock chain.

This change expands the flexibility of rhashtable by removing
restrictive locking that previously limited its use in scheduler
and workqueue contexts.

Import to say that this calls rht_grow_above_75(), which reads from
struct rhashtable without holding the lock, if this is a problem, we can
move the check to the lock, and schedule the workqueue after the lock.


Modified so that atomic_inc is also moved outside of the bucket
lock along with the growth above 75% check.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/ced8ce3c83a7150c5f5d371a8c332d7bc7f9b66d; https://git.kernel.org/stable/c/e1d3422c95f003eba241c176adfe593c33e8a8f6; https://git.kernel.org/stable/c/eb2e58484b838fb4e777ee9721bb9e20e6ca971d
CVE: CVE-2025-21798
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

firewire: test: Fix potential null dereference in firewire kunit test

kunit_kzalloc() may return a NULL pointer, dereferencing it without
NULL check may lead to NULL dereference.
Add a NULL check for test_state.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/352fafe97784e81a10a7c74bd508f71a19b53c2a; https://git.kernel.org/stable/c/70fcb25472d90dd3b87cbee74b9eb68670b0c7b8; https://git.kernel.org/stable/c/c6896bf4c611c3dd126f3e03685f2360a18b3d6f
CVE: CVE-2025-21799
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()

When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns
negative error value on error. So not NULL check is not sufficient
to deteremine if IRQ is valid. Check that IRQ is greater then zero
to ensure it is valid.

There is no issue at probe time but at runtime user can invoke
.set_channels which results in the following call chain.
am65_cpsw_set_channels()
 am65_cpsw_nuss_update_tx_rx_chns()
  am65_cpsw_nuss_remove_tx_chns()
  am65_cpsw_nuss_init_tx_chns()

At this point if am65_cpsw_nuss_init_tx_chns() fails due to
k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a
negative value.

Then, at subsequent .set_channels with higher channel count we
will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()
leading to a kernel warning.

The issue is present in the original commit that introduced this driver,
although there, am65_cpsw_nuss_update_tx_rx_chns() existed as
am65_cpsw_nuss_update_tx_chns().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/321990fdf4f1bb64e818c7140688bf33d129e48d; https://git.kernel.org/stable/c/4395a44acb15850e492dd1de9ec4b6479d96bc80; https://git.kernel.org/stable/c/8448c87b3af68bebca21e3136913f7f77e363515
CVE: CVE-2025-21800
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: HWS, fix definer's HWS_SET32 macro for negative offset

When bit offset for HWS_SET32 macro is negative,
UBSAN complains about the shift-out-of-bounds:

  UBSAN: shift-out-of-bounds in
  drivers/net/ethernet/mellanox/mlx5/core/steering/hws/definer.c:177:2
  shift exponent -8 is negative
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/69c676c0ded472713e6d1b3a456b3c4f52f66f0e; https://git.kernel.org/stable/c/92cff996624c4757d5bbace3dfa3f1567ba94143; https://git.kernel.org/stable/c/be482f1d10da781db9445d2753c1e3f1fd82babf
CVE: CVE-2025-21801
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ravb: Fix missing rtnl lock in suspend/resume path

Fix the suspend/resume path by ensuring the rtnl lock is held where
required. Calls to ravb_open, ravb_close and wol operations must be
performed under the rtnl lock to prevent conflicts with ongoing ndo
operations.

Without this fix, the following warning is triggered:
[   39.032969] =============================
[   39.032983] WARNING: suspicious RCU usage
[   39.033019] -----------------------------
[   39.033033] drivers/net/phy/phy_device.c:2004 suspicious
rcu_dereference_protected() usage!
...
[   39.033597] stack backtrace:
[   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted
6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7
[   39.033623] Hardware name: Renesas SMARC EVK version 2 based on
r9a08g045s33 (DT)
[   39.033628] Call trace:
[   39.033633]  show_stack+0x14/0x1c (C)
[   39.033652]  dump_stack_lvl+0xb4/0xc4
[   39.033664]  dump_stack+0x14/0x1c
[   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c
[   39.033682]  phy_detach+0x160/0x190
[   39.033694]  phy_disconnect+0x40/0x54
[   39.033703]  ravb_close+0x6c/0x1cc
[   39.033714]  ravb_suspend+0x48/0x120
[   39.033721]  dpm_run_callback+0x4c/0x14c
[   39.033731]  device_suspend+0x11c/0x4dc
[   39.033740]  dpm_suspend+0xdc/0x214
[   39.033748]  dpm_suspend_start+0x48/0x60
[   39.033758]  suspend_devices_and_enter+0x124/0x574
[   39.033769]  pm_suspend+0x1ac/0x274
[   39.033778]  state_store+0x88/0x124
[   39.033788]  kobj_attr_store+0x14/0x24
[   39.033798]  sysfs_kf_write+0x48/0x6c
[   39.033808]  kernfs_fop_write_iter+0x118/0x1a8
[   39.033817]  vfs_write+0x27c/0x378
[   39.033825]  ksys_write+0x64/0xf4
[   39.033833]  __arm64_sys_write+0x18/0x20
[   39.033841]  invoke_syscall+0x44/0x104
[   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4
[   39.033862]  do_el0_svc+0x18/0x20
[   39.033870]  el0_svc+0x3c/0xf0
[   39.033880]  el0t_64_sync_handler+0xc0/0xc4
[   39.033888]  el0t_64_sync+0x154/0x158
[   39.041274] ravb 11c30000.ethernet eth0: Link is Down
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]cf291edfbc318d3255a93439f368e4; https://git.kernel.org/stable/c/2c2ebb2b49573e5f8726112ad06b1dffc3c9ea03; https://git.kernel.org/stable/c/ad19522c007bb24ed874468f8baa1503c4662cf4
CVE: CVE-2025-21802
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix oops when unload drivers paralleling

When unload hclge driver, it tries to disable sriov first for each
ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at
the time, because it removes all the ae_dev nodes, and it may cause
oops.

But we can't simply use hnae3_common_lock for this. Because in the
process flow of pci_disable_sriov(), it will trigger the remove flow
of VF, which will also take hnae3_common_lock.

To fixes it, introduce a new mutex to protect the unload process.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/622d92a67656e5c4d2d6ccac02d688ed995418c6; https://git.kernel.org/stable/c/82736bb83fb0221319c85c2e9917d0189cd84e1e; https://git.kernel.org/stable/c/8c640dd3d900cc8988a39c007591f1deee776df4
CVE: CVE-2025-21803
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Fix warnings during S3 suspend

The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),
and the later one may call the preempt_schedule_common() function,
resulting in a thread switch and causing the CPU to be in an interrupt
enabled state after the enable_gpe_wakeup() function returns, leading
to the warnings as follow.

[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8
[ C0]          ...
[ C0] Call Trace:
[ C0] [<[PII_REDACTED]2243b4>] show_stack+0x64/0x188
[ C0] [<[PII_REDACTED]64673c>] dump_stack_lvl+0x60/0x88
[ C0] [<[PII_REDACTED]2687e4>] __warn+0x8c/0x148
[ C0] [<[PII_REDACTED]5e9978>] report_bug+0x1c0/0x2b0
[ C0] [<[PII_REDACTED]6478e4>] do_bp+0x204/0x3b8
[ C0] [<[PII_REDACTED]5b1924>] exception_handlers+0x1924/0x10000
[ C0] [<[PII_REDACTED]343bbc>] ktime_get+0xbc/0xc8
[ C0] [<[PII_REDACTED]354c08>] tick_sched_timer+0x30/0xb0
[ C0] [<[PII_REDACTED]3408e0>] __hrtimer_run_queues+0x160/0x378
[ C0] [<[PII_REDACTED]341f14>] hrtimer_interrupt+0x144/0x388
[ C0] [<[PII_REDACTED]>] constant_timer_interrupt+0x38/0x48
[ C0] [<[PII_REDACTED]2feba4>] __handle_irq_event_percpu+0x64/0x1e8
[ C0] [<[PII_REDACTED]2fed48>] handle_irq_event_percpu+0x20/0x80
[ C0] [<[PII_REDACTED]306b9c>] handle_percpu_irq+0x5c/0x98
[ C0] [<[PII_REDACTED]2fd4a0>] generic_handle_domain_irq+0x30/0x48
[ C0] [<[PII_REDACTED]d0c7b0>] handle_cpu_irq+0x70/0xa8
[ C0] [<[PII_REDACTED]646b30>] handle_loongarch_irq+0x30/0x48
[ C0] [<[PII_REDACTED]646bc8>] do_vint+0x80/0xe0
[ C0] [<[PII_REDACTED]2aea1c>] finish_task_switch.isra.0+0x8c/0x2a8
[ C0] [<[PII_REDACTED]64e34c>] __schedule+0x314/0xa48
[ C0] [<[PII_REDACTED]64ead8>] schedule+0x58/0xf0
[ C0] [<[PII_REDACTED]294a2c>] worker_thread+0x224/0x498
[ C0] [<[PII_REDACTED]29d2f0>] kthread+0xf8/0x108
[ C0] [<[PII_REDACTED]221f28>] ret_from_kernel_thread+0xc/0xa4
[ C0]
[ C0] ---[ end trace [PII_REDACTED] ]---

The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect
acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause
a thread switch. Since there is no longer concurrent execution during
loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()
directly in enable_gpe_wakeup().

The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid
breaking S3 wakeup due to might_sleep()").
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/194d26a5a43c26dc98a9b4e2c1d521dcb84dd1bf; https://git.kernel.org/stable/c/26c0a2d93af55d30a46d5f45d3e9c42cde730168; https://git.kernel.org/stable/c/8682a71a7f6de7c683f31b4334b04e19685a05f9
CVE: CVE-2025-21804
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()

The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()
macro to request a needed resource. A string variable that lives on the
stack is then used to store a dynamically computed resource name, which
is then passed on as one of the macro arguments. This can lead to
undefined behavior.

Depending on the current contents of the memory, the manifestations of
errors may vary. One possible output may be as follows:

  $ cat /proc/iomem
  30000000-37ffffff :
  38000000-3fffffff :

Sometimes, garbage may appear after the colon.

In very rare cases, if no NULL-terminator is found in memory, the system
might crash because the string iterator will overrun which can lead to
access of unmapped memory above the stack.

Thus, fix this by replacing outbound_name with the name of the previously
requested resource. With the changes applied, the output will be as
follows:

  $ cat /proc/iomem
  30000000-37ffffff : memory2
  38000000-3fffffff : memory3

[kwilczynski: commit log]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/24576899c49509c0d533bcf569139f691d8f7af7; https://git.kernel.org/stable/c/2c54b9fca1755e80a343ccfde0652dc5ea4744b2; https://git.kernel.org/stable/c/2d2da5a4c1b4509f6f7e5a8db015cd420144beb4
CVE: CVE-2025-21805
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs: Add missing deinit() call

A warning is triggered when repeatedly connecting and disconnecting the
rnbd:
 list_add corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340).
 WARNING: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0
 Workqueue: ib_cm cm_work_handler [ib_cm]
 RIP: 0010:__list_add_valid_or_report+0x7f/0xa0
  ? __list_add_valid_or_report+0x7f/0xa0
  ib_register_event_handler+0x65/0x93 [ib_core]
  rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server]
  rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core]
  __alloc_path+0x46c/0x680 [rtrs_server]
  ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]
  ? rcu_is_watching+0xd/0x40
  ? __mutex_lock+0x312/0xcf0
  ? get_or_create_srv+0xad/0x310 [rtrs_server]
  ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]
  rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server]
  ? __lock_release+0x1b1/0x2d0
  cma_cm_event_handler+0x4a/0x1a0 [rdma_cm]
  cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm]
  cm_process_work+0x28/0x1a0 [ib_cm]
  ? _raw_spin_unlock_irq+0x2f/0x50
  cm_req_handler+0x618/0xa60 [ib_cm]
  cm_work_handler+0x71/0x520 [ib_cm]

Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a
new element .deinit but never used it at all. Fix it by invoking the
`deinit()` to appropriately unregister the IB event handler.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1af2c769032b6b334cd2a867d7d8c7cbbc527b2d; https://git.kernel.org/stable/c/5a79cc9bc961fafe90787f86e8f53ba6fad8d63b; https://git.kernel.org/stable/c/81468c4058a62e84e475433b83b3edc613294f5e
CVE: CVE-2025-21806
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: let net.core.dev_weight always be non-zero

The following problem was encountered during stability test:

(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \
	returned 1, exceeding its budget of 0.
------------[ cut here ]------------
list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \
	next=ffff88905f746e40.
WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \
	__list_add_valid_or_report+0xf3/0x130
CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+
RIP: 0010:__list_add_valid_or_report+0xf3/0x130
Call Trace:
? __warn+0xcd/0x250
? __list_add_valid_or_report+0xf3/0x130
enqueue_to_backlog+0x923/0x1070
netif_rx_internal+0x92/0x2b0
__netif_rx+0x15/0x170
loopback_xmit+0x2ef/0x450
dev_hard_start_xmit+0x103/0x490
__dev_queue_xmit+0xeac/0x1950
ip_finish_output2+0x6cc/0x1620
ip_output+0x161/0x270
ip_push_pending_frames+0x155/0x1a0
raw_sendmsg+0xe13/0x1550
__sys_sendto+0x3bf/0x4e0
__x64_sys_sendto+0xdc/0x1b0
do_syscall_64+0x5b/0x170
entry_SYSCALL_64_after_hwframe+0x76/0x7e

The reproduction command is as follows:
  sysctl -w net.core.dev_weight=0
  ping 127.0.0.1

This is because when the napi's weight is set to 0, process_backlog() may
return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this
napi to be re-polled in net_rx_action() until __do_softirq() times out.
Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can
be retriggered in enqueue_to_backlog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is
not namespaced).
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0e2f1d93d287d544d26f8ff293ea820a8079b9f8; https://git.kernel.org/stable/c/1489824e5226a26841c70639ebd2d1aed390764b; https://git.kernel.org/stable/c/33e2168788f8fb5cb8bd4f36cb1ef37d1d34dada
CVE: CVE-2025-21807
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

block: fix queue freeze vs limits lock order in sysfs store methods

queue_attr_store() always freezes a device queue before calling the
attribute store operation. For attributes that control queue limits, the
store operation will also lock the queue limits with a call to
queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may
need to issue commands to a device to obtain limit values from the
hardware with the queue limits locked. This creates a potential ABBA
deadlock situation if a user attempts to modify a limit (thus freezing
the device queue) while the device driver starts a revalidation of the
device queue limits.

Avoid such deadlock by not freezing the queue before calling the
->store_limit() method in struct queue_sysfs_entry and instead use the
queue_limits_commit_update_frozen helper to freeze the queue after taking
the limits lock.

This also removes taking the sysfs lock for the store_limit method as
it doesn't protect anything here, but creates even more nesting.
Hopefully it will go away from the actual sysfs methods entirely soon.

(commit log adapted from a similar patch from  Damien Le Moal)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/8985da5481562e96b95e94ed8e5cc9b6565eb82b; https://git.kernel.org/stable/c/c99f66e4084a62a2cc401c4704a84328aeddc9ec
CVE: CVE-2025-21808
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

net: xdp: Disallow attaching device-bound programs in generic mode

Device-bound programs are used to support RX metadata kfuncs. These
kfuncs are driver-specific and rely on the driver context to read the
metadata. This means they can't work in generic XDP mode. However, there
is no check to disallow such programs from being attached in generic
mode, in which case the metadata kfuncs will be called in an invalid
context, leading to crashes.

Fix this by adding a check to disallow attaching device-bound programs
in generic mode.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3595599fa8360bb3c7afa7ee50c810b4a64106ea; https://git.kernel.org/stable/c/557707906dd3e34b8a8c265f664d19f95799937e; https://git.kernel.org/stable/c/5a9eae683d6c36e8a7aa31e5eb8b369e41aa66e1
CVE: CVE-2025-21810
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

driver core: class: Fix wild pointer dereferences in API class_dev_iter_next()

There are a potential wild pointer dereferences issue regarding APIs
class_dev_iter_(init|next|exit)(), as explained by below typical usage:

// All members of @iter are wild pointers.
struct class_dev_iter iter;

// class_dev_iter_init(@iter, @class, ...) checks parameter @class for
// potential class_to_subsys() error, and it returns void type and does
// not initialize its output parameter @iter, so caller can not detect
// the error and continues to invoke class_dev_iter_next(@iter) even if
// @iter still contains wild pointers.
class_dev_iter_init(&iter, ...);

// Dereference these wild pointers in @iter here once suffer the error.
while (dev = class_dev_iter_next(&iter)) { ... };

// Also dereference these wild pointers here.
class_dev_iter_exit(&iter);

Actually, all callers of these APIs have such usage pattern in kernel tree.
Fix by:
- Initialize output parameter @iter by memset() in class_dev_iter_init()
  and give callers prompt by pr_crit() for the error.
- Check if @iter is valid in class_dev_iter_next().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1614e75d1a1b63db6421c7a4bf37004720c7376c; https://git.kernel.org/stable/c/5c504e9767b947cf7d4e29b811c0c8b3c53242b7; https://git.kernel.org/stable/c/e128f82f7006991c99a58114f70ef61e937b1ac1
CVE: CVE-2025-21811
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: protect access to buffers with no active references

nilfs_lookup_dirty_data_buffers(), which iterates through the buffers
attached to dirty data folios/pages, accesses the attached buffers without
locking the folios/pages.

For data cache, nilfs_clear_folio_dirty() may be called asynchronously
when the file system degenerates to read only, so
nilfs_lookup_dirty_data_buffers() still has the potential to cause use
after free issues when buffers lose the protection of their dirty state
midway due to this asynchronous clearing and are unintentionally freed by
try_to_free_buffers().

Eliminate this race issue by adjusting the lock section in this function.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/367a9bffabe08c04f6d725032cce3d891b2b9e1a; https://git.kernel.org/stable/c/4b08d23d7d1917bef4fbee8ad81372f49b006656; https://git.kernel.org/stable/c/58c27fa7a610b6e8d44e6220e7dbddfbaccaf439
CVE: CVE-2025-21813
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

timers/migration: Fix off-by-one root mis-connection

Before attaching a new root to the old root, the children counter of the
new root is checked to verify that only the upcoming CPU's top group have
been connected to it. However since the recently added commit b729cc1ec21a
("timers/migration: Fix another race between hotplug and idle entry/exit")
this check is not valid anymore because the old root is pre-accounted
as a child to the new root. Therefore after connecting the upcoming
CPU's top group to the new root, the children count to be expected must
be 2 and not 1 anymore.

This omission results in the old root to not be connected to the new
root. Then eventually the system may run with more than one top level,
which defeats the purpose of a single idle migrator.

Also the old root is pre-accounted but not connected upon the new root
creation. But it can be connected to the new root later on. Therefore
the old root may be accounted twice to the new root. The propagation of
such overcommit can end up creating a double final top-level root with a
groupmask incorrectly initialized. Although harmless given that the final
top level roots will never have a parent to walk up to, this oddity
opportunistically reported the core issue:

  WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote
  CPU: 8 UID: 0 PID: 0 Comm: swapper/8
  RIP: 0010:tmigr_requires_handle_remote
  Call Trace:
   <IRQ>
   ? tmigr_requires_handle_remote
   ? hrtimer_run_queues
   update_process_times
   tick_periodic
   tick_handle_periodic
   __sysvec_apic_timer_interrupt
   sysvec_apic_timer_interrupt
  </IRQ>

Fix the problem by taking the old root into account in the children count
of the new root so the connection is not omitted.

Also warn when more than one top level group exists to better detect
similar issues in the future.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-193
References: https://git.kernel.org/stable/c/6f449d8fa1808a7f9ee644866bbc079285dbefdd; https://git.kernel.org/stable/c/868c9037df626b3c245ee26a290a03ae1f9f58d3; https://git.kernel.org/stable/c/c6dd70e5b465a2b77c7a7c3d868736d302e29aec
CVE: CVE-2025-21814
Published: 2025-02-27
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: Ensure info->enable callback is always set

The ioctl and sysfs handlers unconditionally call the ->enable callback.
Not all drivers implement that callback, leading to NULL dereferences.
Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.

Instead use a dummy callback if no better was specified by the driver.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1334c64a5d1de6666e0c9f984db6745083df1eb4; https://git.kernel.org/stable/c/5d1041c76de656f9f8d5a192218039a9acf9bd00; https://git.kernel.org/stable/c/755caf4ee1c615ee5717862e427124370f46b1f3