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

platform/mellanox: mlxbf-pmc: add sysfs_attr_init() to count_clock init

The lock-related debug logic (CONFIG_LOCK_STAT) in the kernel is noting
the following warning when the BlueField-3 SOC is booted:

  BUG: key ffff00008a3402a8 has not been registered!
  ------------[ cut here ]------------
  DEBUG_LOCKS_WARN_ON(1)
  WARNING: CPU: 4 PID: 592 at kernel/locking/lockdep.c:4801 lockdep_init_map_type+0x1d4/0x2a0
<snip>
  Call trace:
   lockdep_init_map_type+0x1d4/0x2a0
   __kernfs_create_file+0x84/0x140
   sysfs_add_file_mode_ns+0xcc/0x1cc
   internal_create_group+0x110/0x3d4
   internal_create_groups.part.0+0x54/0xcc
   sysfs_create_groups+0x24/0x40
   device_add+0x6e8/0x93c
   device_register+0x28/0x40
   __hwmon_device_register+0x4b0/0x8a0
   devm_hwmon_device_register_with_groups+0x7c/0xe0
   mlxbf_pmc_probe+0x1e8/0x3e0 [mlxbf_pmc]
   platform_probe+0x70/0x110

The mlxbf_pmc driver must call sysfs_attr_init() during the
initialization of the "count_clock" data structure to avoid
this warning.
References: https://git.kernel.org/stable/c/46be1f5aae82b4136f676528ff091629697c7719; https://git.kernel.org/stable/c/a7b4747d8e0e7871c3d4971cded1dcc9af6af9e9
CVE: CVE-2025-40353
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: mte: Do not warn if the page is already tagged in copy_highpage()

The arm64 copy_highpage() assumes that the destination page is newly
allocated and not MTE-tagged (PG_mte_tagged unset) and warns
accordingly. However, following commit 060913999d7a ("mm: migrate:
support poisoned recover from migrate folio"), folio_mc_copy() is called
before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the
copy will be done again to the same destination page. Since
copy_highpage() already set the PG_mte_tagged flag, this second copy
will warn.

Replace the WARN_ON_ONCE(page already tagged) in the arm64
copy_highpage() with a comment.
References: https://git.kernel.org/stable/c/0bbf3fc6e9211fce9889fe8efbb89c220504d617; https://git.kernel.org/stable/c/5ff5765a1fc526f07d3bbaedb061d970eb13bcf4; https://git.kernel.org/stable/c/b98c94eed4a975e0c80b7e90a649a46967376f58
CVE: CVE-2025-40354
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: increase max link count and fix link->enc NULL pointer access

[why]
1.) dc->links[MAX_LINKS] array size smaller than actual requested.
max_connector + max_dpia + 4 virtual = 14.
increase from 12 to 14.

2.) hw_init() access null LINK_ENC for dpia non display_endpoint.

(cherry picked from commit d7f5a61e1b04ed87b008c8d327649d184dc5bb45)
References: https://git.kernel.org/stable/c/a3fc0d36cfb927f8986b83bf5fba47dbedad3c63; https://git.kernel.org/stable/c/bec947cbe9a65783adb475a5fb47980d7b4f4796; https://git.kernel.org/stable/c/f28092be4e12b7df9e4f415d25bf0d767bc2d9ed
CVE: CVE-2025-40355
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

sysfs: check visibility before changing group attribute ownership

Since commit 0c17270f9b92 ("net: sysfs: Implement is_visible for
phys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() can
hit WARN_ON() when trying to change owner of a file that isn't visible.
See the trace below:

 WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30
 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full)  4b783b4a638669fb644857f484487d17cb45ed1f
 Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025
 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30
 [...]
 Call Trace:
  <TASK>
  ? if6_seq_show+0x30/0x50
  do_setlink.isra.0+0xc7/0x1270
  ? __nla_validate_parse+0x5c/0xcc0
  ? security_capable+0x94/0x1a0
  rtnl_newlink+0x858/0xc20
  ? update_curr+0x8e/0x1c0
  ? update_entity_lag+0x71/0x80
  ? sched_balance_newidle+0x358/0x450
  ? psi_task_switch+0x113/0x2a0
  ? __pfx_rtnl_newlink+0x10/0x10
  rtnetlink_rcv_msg+0x346/0x3e0
  ? sched_clock+0x10/0x30
  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
  netlink_rcv_skb+0x59/0x110
  netlink_unicast+0x285/0x3c0
  ? __alloc_skb+0xdb/0x1a0
  netlink_sendmsg+0x20d/0x430
  ____sys_sendmsg+0x39f/0x3d0
  ? import_iovec+0x2f/0x40
  ___sys_sendmsg+0x99/0xe0
  __sys_sendmsg+0x8a/0xf0
  do_syscall_64+0x81/0x970
  ? __sys_bind+0xe3/0x110
  ? syscall_exit_work+0x143/0x1b0
  ? do_syscall_64+0x244/0x970
  ? sock_alloc_file+0x63/0xc0
  ? syscall_exit_work+0x143/0x1b0
  ? do_syscall_64+0x244/0x970
  ? alloc_fd+0x12e/0x190
  ? put_unused_fd+0x2a/0x70
  ? do_sys_openat2+0xa2/0xe0
  ? syscall_exit_work+0x143/0x1b0
  ? do_syscall_64+0x244/0x970
  ? exc_page_fault+0x7e/0x1a0
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 [...]
  </TASK>

Fix this by checking is_visible() before trying to touch the attribute.
References: https://git.kernel.org/stable/c/ac2c526e103285d80a0330b91a318f6c9276d35a; https://git.kernel.org/stable/c/c7fbb8218b4ad35fec0bd2256d2b9c8d60331f33
CVE: CVE-2025-40356
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: rockchip-sfc: Fix DMA-API usage

Use DMA-API dma_map_single() call for getting the DMA address of the
transfer buffer instead of hacking with virt_to_phys().

This fixes the following DMA-API debug warning:
------------[ cut here ]------------
DMA-API: rockchip-sfc fe300000.spi: device driver tries to sync DMA memory it has not allocated [device address=0x000000000cf70000] [size=288 bytes]
WARNING: kernel/dma/debug.c:1106 at check_sync+0x1d8/0x690, CPU#2: systemd-udevd/151
Modules linked in: ...
Hardware name: Hardkernel ODROID-M1 (DT)
pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : check_sync+0x1d8/0x690
lr : check_sync+0x1d8/0x690
..
Call trace:
 check_sync+0x1d8/0x690 (P)
 debug_dma_sync_single_for_cpu+0x84/0x8c
 __dma_sync_single_for_cpu+0x88/0x234
 rockchip_sfc_exec_mem_op+0x4a0/0x798 [spi_rockchip_sfc]
 spi_mem_exec_op+0x408/0x498
 spi_nor_read_data+0x170/0x184
 spi_nor_read_sfdp+0x74/0xe4
 spi_nor_parse_sfdp+0x120/0x11f0
 spi_nor_sfdp_init_params_deprecated+0x3c/0x8c
 spi_nor_scan+0x690/0xf88
 spi_nor_probe+0xe4/0x304
 spi_mem_probe+0x6c/0xa8
 spi_probe+0x94/0xd4
 really_probe+0xbc/0x298
 ...
References: https://git.kernel.org/stable/c/22810d4cb0e8a7d51b24527e73beac60afc1c693; https://git.kernel.org/stable/c/ee795e82e10197c070efd380dc9615c73dffad6c
CVE: CVE-2025-40358
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: stacktrace: Disable KASAN checks for non-current tasks

Unwinding the stack of a task other than current, KASAN would report
"BUG: KASAN: out-of-bounds in walk_stackframe+0x41c/0x460"

There is a same issue on x86 and has been resolved by the commit
84936118bdf3 ("x86/unwind: Disable KASAN checks for non-current tasks")
The solution could be applied to RISC-V too.

This patch also can solve the issue:
https://seclists.org/oss-sec/2025/q4/23

[pjw@kernel.org: clean up checkpatch issues]
References: https://git.kernel.org/stable/c/060ea84a484e852b52b938f234bf9b5503a6c910; https://git.kernel.org/stable/c/27379fcc15a10d3e3780fe79ba3fc7ed1ccd78e2; https://git.kernel.org/stable/c/2c8d2b53866fb229b438296526ef0fa5a990e5e5
CVE: CVE-2025-40359
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Fix KASAN global-out-of-bounds warning

When running "perf mem record" command on CWF, the below KASAN
global-out-of-bounds warning is seen.

  ==================================================================
  BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0
  Read of size 4 at addr ffffffffb721d000 by task dtlb/9850

  Call Trace:

   kasan_report+0xb8/0xf0
   cmt_latency_data+0x176/0x1b0
   setup_arch_pebs_sample_data+0xf49/0x2560
   intel_pmu_drain_arch_pebs+0x577/0xb00
   handle_pmi_common+0x6c4/0xc80

The issue is caused by below code in __grt_latency_data(). The code
tries to access x86_hybrid_pmu structure which doesn't exist on
non-hybrid platform like CWF.

        WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)

So add is_hybrid() check before calling this WARN_ON_ONCE to fix the
global-out-of-bounds access issue.
References: https://git.kernel.org/stable/c/0ba6502ce167fc3d598c08c2cc3b4ed7ca5aa251; https://git.kernel.org/stable/c/1b61a1da3d8105ea1be548c94c2856697eb7ffd1; https://git.kernel.org/stable/c/710a72e81a7028e1ad1a10eb14f941f8dd45ffd3
CVE: CVE-2025-40360
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/sysfb: Do not dereference NULL pointer in plane reset

The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not
deref that pointer, but forward NULL to the other plane-reset helpers.
Clears plane->state to NULL.

v2:
- fix typo in commit description (Javier)
References: https://git.kernel.org/stable/c/14e02ed3876f4ab0ed6d3f41972175f8b8df3d70; https://git.kernel.org/stable/c/6abeff03cb79a2c7f4554a8e8738acd35bb37152; https://git.kernel.org/stable/c/6bdef5648a60e49d4a3b02461ab7ae3776877e77
CVE: CVE-2025-40361
Published: 2025-12-16
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-40362
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: fix multifs mds auth caps issue

The mds auth caps check should also validate the
fsname along with the associated caps. Not doing
so would result in applying the mds auth caps of
one fs on to the other fs in a multifs ceph cluster.
The bug causes multiple issues w.r.t user
authentication, following is one such example.

Steps to Reproduce (on vstart cluster):
1. Create two file systems in a cluster, say 'fsname1' and 'fsname2'
2. Authorize read only permission to the user 'client.usr' on fs 'fsname1'
    $ceph fs authorize fsname1 client.usr / r
3. Authorize read and write permission to the same user 'client.usr' on fs 'fsname2'
    $ceph fs authorize fsname2 client.usr / rw
4. Update the keyring
    $ceph auth get client.usr >> ./keyring

With above permssions for the user 'client.usr', following is the
expectation.
  a. The 'client.usr' should be able to only read the contents
     and not allowed to create or delete files on file system 'fsname1'.
  b. The 'client.usr' should be able to read/write on file system 'fsname2'.

But, with this bug, the 'client.usr' is allowed to read/write on file
system 'fsname1'. See below.

5. Mount the file system 'fsname1' with the user 'client.usr'
     $sudo bin/mount.ceph usr@.fsname1=/ /kmnt_fsname1_usr/
6. Try creating a file on file system 'fsname1' with user 'client.usr'. This
   should fail but passes with this bug.
     $touch /kmnt_fsname1_usr/file1
7. Mount the file system 'fsname1' with the user 'client.admin' and create a
   file.
     $sudo bin/mount.ceph admin@.fsname1=/ /kmnt_fsname1_admin
     $echo "data" > /kmnt_fsname1_admin/admin_file1
8. Try removing an existing file on file system 'fsname1' with the user
   'client.usr'. This shoudn't succeed but succeeds with the bug.
     $rm -f /kmnt_fsname1_usr/admin_file1

For more information, please take a look at the corresponding mds/fuse patch
and tests added by looking into the tracker mentioned below.

v2: Fix a possible null dereference in doutc
v3: Don't store fsname from mdsmap, validate against
    ceph_mount_options's fsname and use it
v4: Code refactor, better warning message and
    fix possible compiler warning

[ Slava.Dubeyko: "fsname check failed" -> "fsname mismatch" ]
References: https://git.kernel.org/stable/c/07640d34a781bb2e39020a39137073c03c4aa932; https://git.kernel.org/stable/c/22c73d52a6d05c5a2053385c0d6cd[PII_REDACTED]d; https://git.kernel.org/stable/c/ca3da8b27ab9a0923ad477447cfb8fc7f4b4c523
CVE: CVE-2025-40363
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ipv6: fix field-spanning memcpy warning in AH output

Fix field-spanning memcpy warnings in ah6_output() and
ah6_output_done() where extension headers are copied to/from IPv6
address fields, triggering fortify-string warnings about writes beyond
the 16-byte address fields.

  memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16)
  WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439

The warnings are false positives as the extension headers are
intentionally placed after the IPv6 header in memory. Fix by properly
copying addresses and extension headers separately, and introduce
helper functions to avoid code duplication.
References: https://git.kernel.org/stable/c/0bf756ae1e69fec5e6332c[PII_REDACTED]5d6d771b; https://git.kernel.org/stable/c/2327a3d6f65ce2fe2634546dde4a25ef52296fec; https://git.kernel.org/stable/c/2da805a61ef5272a2773775ce14c3650adb84248
CVE: CVE-2025-68167
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

gpiolib: fix invalid pointer access in debugfs

If the memory allocation in gpiolib_seq_start() fails, the s->private
field remains uninitialized and is later dereferenced without checking
in gpiolib_seq_stop(). Initialize s->private to NULL before calling
kzalloc() and check it before dereferencing it.
References: https://git.kernel.org/stable/c/2f6115ad8864cf3f48598f26c74c7c8e5c391919; https://git.kernel.org/stable/c/3c91c8f424d3e44c8645ab765a38773e58afb07d; https://git.kernel.org/stable/c/70180a[PII_REDACTED]c93ed2f47c41803268bdd91c
CVE: CVE-2025-68168
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: fix uninitialized waitqueue in transaction manager

The transaction manager initialization in txInit() was not properly
initializing TxBlock[0].waitor waitqueue, causing a crash when
txEnd(0) is called on read-only filesystems.

When a filesystem is mounted read-only, txBegin() returns tid=0 to
indicate no transaction. However, txEnd(0) still gets called and
tries to access TxBlock[0].waitor via tid_to_tblock(0), but this
waitqueue was never initialized because the initialization loop
started at index 1 instead of 0.

This causes a 'non-static key' lockdep warning and system crash:
  INFO: trying to register non-static key in txEnd

Fix by ensuring all transaction blocks including TxBlock[0] have
their waitqueues properly initialized during txInit().
References: https://git.kernel.org/stable/c/038861414ab383b41dd35abbf9ff0ef715592d53; https://git.kernel.org/stable/c/2a9575a372182ca075070b3cd77490dcf0c951e7; https://git.kernel.org/stable/c/300b072df72694ea330c4c673c035253e07827b8
CVE: CVE-2025-68169
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

netpoll: Fix deadlock in memory allocation under spinlock

Fix a AA deadlock in refill_skbs() where memory allocation while holding
skb_pool->lock can trigger a recursive lock acquisition attempt.

The deadlock scenario occurs when the system is under severe memory
pressure:

1. refill_skbs() acquires skb_pool->lock (spinlock)
2. alloc_skb() is called while holding the lock
3. Memory allocator fails and calls slab_out_of_memory()
4. This triggers printk() for the OOM warning
5. The console output path calls netpoll_send_udp()
6. netpoll_send_udp() attempts to acquire the same skb_pool->lock
7. Deadlock: the lock is already held by the same CPU

Call stack:
  refill_skbs()
    spin_lock_irqsave(&skb_pool->lock)    <- lock acquired
    __alloc_skb()
      kmem_cache_alloc_node_noprof()
        slab_out_of_memory()
          printk()
            console_flush_all()
              netpoll_send_udp()
                skb_dequeue()
                  spin_lock_irqsave(&skb_pool->lock)     <- deadlock attempt

This bug was exposed by commit 248f6571fd4c51 ("netpoll: Optimize skb
refilling on critical path") which removed refill_skbs() from the
critical path (where nested printk was being deferred), letting nested
printk being called from inside refill_skbs()

Refactor refill_skbs() to never allocate memory while holding
the spinlock.

Another possible solution to fix this problem is protecting the
refill_skbs() from nested printks, basically calling
printk_deferred_{enter,exit}() in refill_skbs(), then, any nested
pr_warn() would be deferred.

I prefer this approach, given I _think_ it might be a good idea to move
the alloc_skb() from GFP_ATOMIC to GFP_KERNEL in the future, so, having
the alloc_skb() outside of the lock will be necessary step.

There is a possible TOCTOU issue when checking for the pool length, and
queueing the new allocated skb, but, this is not an issue, given that
an extra SKB in the pool is harmless and it will be eventually used.
References: https://git.kernel.org/stable/c/06742a3ab884d7428c9050b205ffcf6a8a548397; https://git.kernel.org/stable/c/327c20c21d80e0d87834b392d83ae73c955ad8ff
CVE: CVE-2025-68170
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: Do not kfree() devres managed rdev

Since the allocation of the drivers main structure was changed to
devm_drm_dev_alloc() rdev is managed by devres and we shouldn't be calling
kfree() on it.

This fixes things exploding if the driver probe fails and devres cleans up
the rdev after we already free'd it.

(cherry picked from commit 16c0681617b8a045773d4d87b6140002fa75b03b)
References: https://git.kernel.org/stable/c/2413bbd1d692aed245c2aa38a369a1fa7590db84; https://git.kernel.org/stable/c/[PII_REDACTED]a0895fd9c096edfe8ecd372ca9145e; https://git.kernel.org/stable/c/f[PII_REDACTED]a11317912e29577bbf33cf59a0fb1
CVE: CVE-2025-68171
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Ensure XFD state on signal delivery

Sean reported [1] the following splat when running KVM tests:

   WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70
   Call Trace:
    <TASK>
    fpu__clear_user_states+0x9c/0x100
    arch_do_signal_or_restart+0x142/0x210
    exit_to_user_mode_loop+0x55/0x100
    do_syscall_64+0x205/0x2c0
    entry_SYSCALL_64_after_hwframe+0x4b/0x53

Chao further identified [2] a reproducible scenario involving signal
delivery: a non-AMX task is preempted by an AMX-enabled task which
modifies the XFD MSR.

When the non-AMX task resumes and reloads XSTATE with init values,
a warning is triggered due to a mismatch between fpstate::xfd and the
CPU's current XFD state. fpu__clear_user_states() does not currently
re-synchronize the XFD state after such preemption.

Invoke xfd_update_state() which detects and corrects the mismatch if
there is a dynamic feature.

This also benefits the sigreturn path, as fpu__restore_sig() may call
fpu__clear_user_states() when the sigframe is inaccessible.

[ dhansen: minor changelog munging ]
References: https://git.kernel.org/stable/c/1811c610653c0cd21cc9add14595b7cffaeca511; https://git.kernel.org/stable/c/388eff894d6bc5f921e9bfff0e4b0ab2684a96e9; https://git.kernel.org/stable/c/3f735419c4b43cde42e6d408db39137b82474e31
CVE: CVE-2025-68172
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: aspeed - fix double free caused by devm

The clock obtained via devm_clk_get_enabled() is automatically managed
by devres and will be disabled and freed on driver detach. Manually
calling clk_disable_unprepare() in error path and remove function
causes double free.

Remove the manual clock cleanup in both aspeed_acry_probe()'s error
path and aspeed_acry_remove().
References: https://git.kernel.org/stable/c/0dd6474ced33489076e6c0f3fe5077bf12e85b28; https://git.kernel.org/stable/c/29d[PII_REDACTED]a7e1ffbd09a6118018d5954a6e5; https://git.kernel.org/stable/c/3c9bf72cc1ced1297b235f9422d62b613a3fdae9
CVE: CVE-2025-68173
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ftrace: Fix softlockup in ftrace_module_enable

A soft lockup was observed when loading amdgpu module.
If a module has a lot of tracable functions, multiple calls
to kallsyms_lookup can spend too much time in RCU critical
section and with disabled preemption, causing kernel panic.
This is the same issue that was fixed in
commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY
kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to
ftrace_graph_set_hash()").

Fix it the same way by adding cond_resched() in ftrace_module_enable.
References: https://git.kernel.org/stable/c/4099b98203d6b33d990586542fa5beee408032a3; https://git.kernel.org/stable/c/40c8ee40e48a2c82c762539952ed8fc0571db5bf; https://git.kernel.org/stable/c/7e3c96010ade29bb340a5bdce8675f50c7f59001
CVE: CVE-2025-68176
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: cadence: Check for the existence of cdns_pcie::ops before using it

cdns_pcie::ops might not be populated by all the Cadence glue drivers. This
is going to be true for the upcoming Sophgo platform which doesn't set the
ops.

Hence, add a check to prevent NULL pointer dereference.

[mani: reworded subject and description]
References: https://git.kernel.org/stable/c/0d0bb756f002810d249caee51f3f1c309f3cdab5; https://git.kernel.org/stable/c/1810b2fd7375de88a74976dcd402b29088e479ed; https://git.kernel.org/stable/c/363448d069e29685ca37a118065121e486387af3
CVE: CVE-2025-68177
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq/longhaul: handle NULL policy in longhaul_exit

longhaul_exit() was calling cpufreq_cpu_get(0) without checking
for a NULL policy pointer. On some systems, this could lead to a
NULL dereference and a kernel warning or panic.

This patch adds a check using unlikely() and returns early if the
policy is NULL.

Bugzilla: #219962
References: https://git.kernel.org/stable/c/55cf586b9556863e3c2a45460aba71bcb2be5bcd; https://git.kernel.org/stable/c/592532a77b736b5153e0c2e4c74aa50af0a352ab; https://git.kernel.org/stable/c/64adabb6d9d51b7e7c02fe733346a2c4dd738488
CVE: CVE-2025-68179
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP

As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible
crashes. The problem is that kernel page tables are modified without
flushing corresponding TLB entries.

Even if it looks like the empty flush_tlb_all() implementation on s390 is
the problem, it is actually a different problem: on s390 it is not allowed
to replace an active/valid page table entry with another valid page table
entry without the detour over an invalid entry. A direct replacement may
lead to random crashes and/or data corruption.

In order to invalidate an entry special instructions have to be used
(e.g. ipte or idte). Alternatively there are also special instructions
available which allow to replace a valid entry with a different valid
entry (e.g. crdte or cspg).

Given that the HVO code currently does not provide the hooks to allow for
an implementation which is compliant with the s390 architecture
requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is
basically a revert of the original patch which enabled it.
References: https://git.kernel.org/stable/c/5e23918e[PII_REDACTED]d13fb511116cdea0234b71; https://git.kernel.org/stable/c/64e2f60f355e556337fcffe80b9bcff1b22c9c42; https://git.kernel.org/stable/c/7088465f10816d9425b95740b37c95f082041d76