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

drm/radeon: Remove calls to drm_put_dev()

Since the allocation of the drivers main structure was changed to
devm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'd
should be done by devres.

However, drm_put_dev() is still in the probe error and device remove
paths. When the driver fails to probe warnings like the following are
shown because devres is trying to drm_put_dev() after the driver
already did it.

[    5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22
[    5.649605] ------------[ cut here ]------------
[    5.649607] refcount_t: underflow; use-after-free.
[    5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110

(cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)
References: https://git.kernel.org/stable/c/2fa41445d8c98f2a65503c[PII_REDACTED]96edc0e7; https://git.kernel.org/stable/c/745bae76acdd71709773c129a69deca01036250b; https://git.kernel.org/stable/c/ec18f6b2c743cc471b2539ddb5caed20a012e640
CVE: CVE-2025-68182
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()

This code frees "link" by calling kfree_rcu(link, rcu_head) and then it
dereferences "link" to get the "link->fw_id".  Save the "link->fw_id"
first to avoid a potential use after free.
References: https://git.kernel.org/stable/c/5b4a239c9f94e1606435f1842fc6fd426d607dbb; https://git.kernel.org/stable/c/77e67d5daaf155f7d0f99f4e797c4842169ec19e
CVE: CVE-2025-68183
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

Currently when both IMA and EVM are in fix mode, the IMA signature will
be reset to IMA hash if a program first stores IMA signature in
security.ima and then writes/removes some other security xattr for the
file.

For example, on Fedora, after booting the kernel with "ima_appraise=fix
evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,
installing/reinstalling a package will not make good reference IMA
signature generated. Instead IMA hash is generated,

    # getfattr -m - -d -e hex /usr/bin/bash
    # file: usr/bin/bash
    security.ima=0x0404...

This happens because when setting security.selinux, the IMA_DIGSIG flag
that had been set early was cleared. As a result, IMA hash is generated
when the file is closed.

Similarly, IMA signature can be cleared on file close after removing
security xattr like security.evm or setting/removing ACL.

Prevent replacing the IMA file signature with a file hash, by preventing
the IMA_DIGSIG flag from being reset.

Here's a minimal C reproducer which sets security.selinux as the last
step which can also replaced by removing security.evm or setting ACL,

    #include <stdio.h>
    #include <sys/xattr.h>
    #include <fcntl.h>
    #include <unistd.h>
    #include <string.h>
    #include <stdlib.h>

    int main() {
        const char* file_path = "/usr/sbin/test_binary";
        const char* hex_string = "030204d[PII_REDACTED][PII_REDACTED]";
        int length = strlen(hex_string);
        char* ima_attr_value;
        int fd;

        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
        if (fd == -1) {
            perror("Error opening file");
            return 1;
        }

        ima_attr_value = (char*)malloc(length / 2 );
        for (int i = 0, j = 0; i < length; i += 2, j++) {
            sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);
        }

        if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {
            perror("Error setting extended attribute");
            close(fd);
            return 1;
        }

        const char* selinux_value= "system_u:object_r:bin_t:s0";
        if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {
            perror("Error setting extended attribute");
            close(fd);
            return 1;
        }

        close(fd);

        return 0;
    }
References: https://git.kernel.org/stable/c/02aa671c08a4834bef5166743a7b88686fbfa023; https://git.kernel.org/stable/c/88b4cbcf6b041ae0f2fc8a34554a5b6a83a2b7cd; https://git.kernel.org/stable/c/d2993a7e98eb70c737c6f5365a190e79c72b8407
CVE: CVE-2025-68184
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Disable AFBC support on Mediatek DRM driver

Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM
driver") added AFBC support to Mediatek DRM and enabled the
32x8/split/sparse modifier.

However, this is currently broken on Mediatek MT8188 (Genio 700 EVK
platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by
default since Mesa v25.0.

Kernel trace reports vblank timeouts constantly, and the render is garbled:

```
[CRTC:62:crtc-0] vblank wait timed out
WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
[...]
Hardware name: MediaTek Genio-700 EVK (DT)
Workqueue: events_unbound commit_work
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
sp : ffff80008337bca0
x29: ffff80008337bcd0 x28: [PII_REDACTED] x27: [PII_REDACTED]
x26: [PII_REDACTED] x25: [PII_REDACTED] x24: ffff0000c9dcc000
x23: [PII_REDACTED] x22: [PII_REDACTED] x21: ffff0000c66f2f80
x20: ffff0000c0d7d880 x19: [PII_REDACTED] x18:[PII_REDACTED]00000a
x17:[PII_REDACTED]44ffff x16: 005000f2b5503510 x15: [PII_REDACTED]
x14: [PII_REDACTED] x13: 74756f2064656d69 x12:[PII_REDACTED]77206b
x11: [PII_REDACTED] x10: [PII_REDACTED] x9 : ffff800082396a70
x8 :[PII_REDACTED]057fa8 x7 :[PII_REDACTED]000cce x6 : ffff8000823eea70
x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480
x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffff0000c12cb480
Call trace:
 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)
 drm_atomic_helper_commit_tail_rpm+0x64/0x80
 commit_tail+0xa4/0x1a4
 commit_work+0x14/0x20
 process_one_work+0x150/0x290
 worker_thread+0x2d0/0x3ec
 kthread+0x12c/0x210
 ret_from_fork+0x10/0x20
---[ end trace [PII_REDACTED] ]---
```

Until this gets fixed upstream, disable AFBC support on this platform, as
it's currently broken with upstream Mesa.
References: https://git.kernel.org/stable/c/0eaa0a3dfe218c4cf1a0782ccbbc9e3931718f17; https://git.kernel.org/stable/c/72223700b620885d556a4c52a63f[PII_REDACTED]c6; https://git.kernel.org/stable/c/9882a40640036d5bbc590426a78981526d4f2345
CVE: CVE-2025-68185
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing

Theoretically it's an oopsable race, but I don't believe one can manage
to hit it on real hardware; might become doable on a KVM, but it still
won't be easy to attack.

Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of
put_unaligned_be64(), we can put that under ->d_lock and be done with that.
References: https://git.kernel.org/stable/c/40be5b9080114f18b0cea386db415b68a7273c1a; https://git.kernel.org/stable/c/504b3fb9948a9e96ebbabdee0d33966a8bab15cb; https://git.kernel.org/stable/c/6025f641a0e30afdc5aa62017397b1860ad9f677
CVE: CVE-2025-68186
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches up

The function ring_buffer_map_get_reader() is a bit more strict than the
other get reader functions, and except for certain situations the
rb_get_reader_page() should not return NULL. If it does, it triggers a
warning.

This warning was triggering but after looking at why, it was because
another acceptable situation was happening and it wasn't checked for.

If the reader catches up to the writer and there's still data to be read
on the reader page, then the rb_get_reader_page() will return NULL as
there's no new page to get.

In this situation, the reader page should not be updated and no warning
should trigger.
References: https://git.kernel.org/stable/c/6f5c4f8109fa4d0955b3712597a26b310bdc736f; https://git.kernel.org/stable/c/aa997d2d2a0b2e76f4df0f1f12829f02acb4fb6b; https://git.kernel.org/stable/c/b42dbef4f[PII_REDACTED]34d5ab71c4129a3ddd1a9
CVE: CVE-2025-68187
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mdio: Check regmap pointer returned by device_node_to_regmap()

The call to device_node_to_regmap() in airoha_mdio_probe() can return
an ERR_PTR() if regmap initialization fails. Currently, the driver
stores the pointer without validation, which could lead to a crash
if it is later dereferenced.

Add an IS_ERR() check and return the corresponding error code to make
the probe path more robust.
References: https://git.kernel.org/stable/c/b2b526c2cf57d14ee269e012ed179081871f45a1; https://git.kernel.org/stable/c/dc8ed3823473bb38ba43cfb34f1e1c1baa22f975
CVE: CVE-2025-68188
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()

Use RCU to avoid a pair of atomic operations and a potential
UAF on dst_dev()->flags.
References: https://git.kernel.org/stable/c/06da08d9355bf8e2070459bbedbe372ccc02cc0e; https://git.kernel.org/stable/c/b62a59c18b692f892dcb8109c1c2e653b2abc95c; https://git.kernel.org/stable/c/bc2b881a0896c111c1041d8bb1f92a3b3873ace5
CVE: CVE-2025-68189
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix GEM free for imported dma-bufs

Imported dma-bufs also have obj->resv != &obj->_resv.  So we should
check both this condition in addition to flags for handling the
_NO_SHARE case.

Fixes this splat that was reported with IRIS video playback:

    ------------[ cut here ]------------
    WARNING: CPU: 3 PID: 2040 at drivers/gpu/drm/msm/msm_gem.c:1127 msm_gem_free_object+0x1f8/0x264 [msm]
    CPU: 3 UID: 1000 PID: 2040 Comm: .gnome-shell-wr Not tainted 6.17.0-rc7 #1 PREEMPT
    pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    pc : msm_gem_free_object+0x1f8/0x264 [msm]
    lr : msm_gem_free_object+0x138/0x264 [msm]
    sp : ffff800092a1bb30
    x29: ffff800092a1bb80 x28: ffff800092a1bce8 x27: ffffbc702dbdbe08
    x26: [PII_REDACTED] x25: [PII_REDACTED] x24:[PII_REDACTED]0000a6
    x23: ffff00083c72f850 x22: ffff00083c72f868 x21: ffff00087e69f200
    x20: ffff00087e69f330 x19: ffff00084d157ae0 x18: [PII_REDACTED]
    x17: [PII_REDACTED] x16: ffffbc704bd46b80 x15: 0000ffffd0959540
    x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
    x11: ffffbc702e6cdb48 x10: [PII_REDACTED] x9 :[PII_REDACTED]00003f
    x8 : ffff800092a1ba90 x7 : [PII_REDACTED] x6 : [PII_REDACTED]
    x5 : ffffbc704bd46c40 x4 : fffffdffe102cf60 x3 : [PII_REDACTED]
    x2 : [PII_REDACTED] x1 : ffff00087e6978e8 x0 : ffff00087e6977e8
    Call trace:
     msm_gem_free_object+0x1f8/0x264 [msm] (P)
     drm_gem_object_free+0x1c/0x30 [drm]
     drm_gem_object_handle_put_unlocked+0x138/0x150 [drm]
     drm_gem_object_release_handle+0x5c/0xcc [drm]
     drm_gem_handle_delete+0x68/0xbc [drm]
     drm_gem_close_ioctl+0x34/0x40 [drm]
     drm_ioctl_kernel+0xc0/0x130 [drm]
     drm_ioctl+0x360/0x4e0 [drm]
     __arm64_sys_ioctl+0xac/0x104
     invoke_syscall+0x48/0x104
     el0_svc_common.constprop.0+0x40/0xe0
     do_el0_svc+0x1c/0x28
     el0_svc+0x34/0xec
     el0t_64_sync_handler+0xa0/0xe4
     el0t_64_sync+0x198/0x19c
    ---[ end trace [PII_REDACTED] ]---
    ------------[ cut here ]------------

Patchwork: https://patchwork.freedesktop.org/patch/676273/
References: https://git.kernel.org/stable/c/9674c4cb2fe62727a2e4d3f66065ab949dfa61be; https://git.kernel.org/stable/c/c34e08ba6c0037a72a[PII_REDACTED]b020c989e4ae
CVE: CVE-2025-68190
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()

kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws
remains NULL while ectx.ws_size is set, leading to a potential NULL
pointer dereference in atom_get_src_int() when accessing WS entries.

Return -ENOMEM on allocation failure to avoid the NULL dereference.
References: https://git.kernel.org/stable/c/35f3fb86bb0158a298d6834e7e110dcaf07f490c; https://git.kernel.org/stable/c/997e28d3d00a1d[PII_REDACTED]5e[PII_REDACTED]205b; https://git.kernel.org/stable/c/cc9a8e238e42c1f43b98c097995137d644b69245
CVE: CVE-2025-68191
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

udp_tunnel: use netdev_warn() instead of netdev_WARN()

netdev_WARN() uses WARN/WARN_ON to print a backtrace along with
file and line information. In this case, udp_tunnel_nic_register()
returning an error is just a failed operation, not a kernel bug.

udp_tunnel_nic_register() can fail due to a memory allocation
failure (kzalloc() or udp_tunnel_nic_alloc()).
This is a normal runtime error and not a kernel bug.

Replace netdev_WARN() with netdev_warn() accordingly.
References: https://git.kernel.org/stable/c/087f1ed450dc6e7e49ffbbbe5b78be1218c6d5e0; https://git.kernel.org/stable/c/3c3b148bf8384c8a787753cf20abde1c5731f97f; https://git.kernel.org/stable/c/45e4e4a8772fa1c5f6f38e82b732b3a9d8137af4
CVE: CVE-2025-68192
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup

Raw IP packets have no MAC header, leaving skb->mac_header uninitialized.
This can trigger kernel panics on ARM64 when xfrm or other subsystems
access the offset due to strict alignment checks.

Initialize the MAC header to prevent such crashes.

This can trigger kernel panics on ARM when running IPsec over the
qmimux0 interface.

Example trace:

    Internal error: Oops:[PII_REDACTED]00004f [#1] SMP
    CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
    Hardware name: LS1028A RDB Board (DT)
    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : xfrm_input+0xde8/0x1318
    lr : xfrm_input+0x61c/0x1318
    sp : ffff800080003b20
    Call trace:
     xfrm_input+0xde8/0x1318
     xfrm6_rcv+0x38/0x44
     xfrm6_esp_rcv+0x48/0xa8
     ip6_protocol_deliver_rcu+0x94/0x4b0
     ip6_input_finish+0x44/0x70
     ip6_input+0x44/0xc0
     ipv6_rcv+0x6c/0x114
     __netif_receive_skb_one_core+0x5c/0x8c
     __netif_receive_skb+0x18/0x60
     process_backlog+0x78/0x17c
     __napi_poll+0x38/0x180
     net_rx_action+0x168/0x2f0
References: https://git.kernel.org/stable/c/0aabccdcec1f4a36f95829ea2263f845bbc77223; https://git.kernel.org/stable/c/4e6b9004f01d0fef5b19778399bc5bf55f8c2d71; https://git.kernel.org/stable/c/8ab3b8f958d861a7f725a5be[PII_REDACTED]9fbd69
CVE: CVE-2025-68193
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/guc: Add devm release action to safely tear down CT

When a buffer object (BO) is allocated with the XE_BO_FLAG_GGTT_INVALIDATE
flag, the driver initiates TLB invalidation requests via the CTB mechanism
while releasing the BO. However a premature release of the CTB BO can lead
to system crashes, as observed in:

Oops: Oops: 0000 [#1] SMP NOPTI
RIP: 0010:h2g_write+0x2f3/0x7c0 [xe]
Call Trace:
 guc_ct_send_locked+0x8b/0x670 [xe]
 xe_guc_ct_send_locked+0x19/0x60 [xe]
 send_tlb_invalidation+0xb4/0x460 [xe]
 xe_gt_tlb_invalidation_ggtt+0x15e/0x2e0 [xe]
 ggtt_invalidate_gt_tlb.part.0+0x16/0x90 [xe]
 ggtt_node_remove+0x110/0x140 [xe]
 xe_ggtt_node_remove+0x40/0xa0 [xe]
 xe_ggtt_remove_bo+0x87/0x250 [xe]

Introduce a devm-managed release action during xe_guc_ct_init() and
xe_guc_ct_init_post_hwconfig() to ensure proper CTB disablement before
resource deallocation, preventing the use-after-free scenario.
References: https://git.kernel.org/stable/c/52faa05fcd9f78af99abebe30a4b7b444744c991; https://git.kernel.org/stable/c/ee4b32220a6b41e71512e[PII_REDACTED]e685456ba
CVE: CVE-2025-68194
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

media: imon: make send_packet() more robust

syzbot is reporting that imon has three problems which result in
hung tasks due to forever holding device lock [1].

First problem is that when usb_rx_callback_intf0() once got -EPROTO error
after ictx->dev_present_intf0 became true, usb_rx_callback_intf0()
resubmits urb after printk(), and resubmitted urb causes
usb_rx_callback_intf0() to again get -EPROTO error. This results in
printk() flooding (RCU stalls).

Alan Stern commented [2] that

  In theory it's okay to resubmit _if_ the driver has a robust
  error-recovery scheme (such as giving up after some fixed limit on the
  number of errors or after some fixed time has elapsed, perhaps with a
  time delay to prevent a flood of errors).  Most drivers don't bother to
  do this; they simply give up right away.  This makes them more
  vulnerable to short-term noise interference during USB transfers, but in
  reality such interference is quite rare.  There's nothing really wrong
  with giving up right away.

but imon has a poor error-recovery scheme which just retries forever;
this behavior should be fixed.

Since I'm not sure whether it is safe for imon users to give up upon any
error code, this patch takes care of only union of error codes chosen from
modules in drivers/media/rc/ directory which handle -EPROTO error (i.e.
ir_toy, mceusb and igorplugusb).

Second problem is that when usb_rx_callback_intf0() once got -EPROTO error
before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always
resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge
hardware after early callbacks"). Move the ictx->dev_present_intf0 test
introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes
until intf configured") to immediately before imon_incoming_packet(), or
the first problem explained above happens without printk() flooding (i.e.
hung task).

Third problem is that when usb_rx_callback_intf0() is not called for some
reason (e.g. flaky hardware; the reproducer for this problem sometimes
prevents usb_rx_callback_intf0() from being called),
wait_for_completion_interruptible() in send_packet() never returns (i.e.
hung task). As a workaround for such situation, change send_packet() to
wait for completion with timeout of 10 seconds.
References: https://git.kernel.org/stable/c/0213e4175abbb9dfcbf7c197e3817d527f459ad5; https://git.kernel.org/stable/c/26f6a1dd5d81ad61a875a747698da6f27abf389b; https://git.kernel.org/stable/c/519737af11c03590819a6eec2ad532cfdb87ea63
CVE: CVE-2025-68195
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcode

Running x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an out
of bounds access.
References: https://git.kernel.org/stable/c/4c6b56a76478bd1ab609827c571905386c11d308; https://git.kernel.org/stable/c/f1fdffe0afea02ba783acfe815b6a60e7180df40
CVE: CVE-2025-68196
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Cache streams targeting link when performing LT automation

[WHY]
Last LT automation update can cause crash by referencing current_state and
calling into dc_update_planes_and_stream which may clobber current_state.

[HOW]
Cache relevant stream pointers and iterate through them instead of relying
on the current_state.
References: https://git.kernel.org/stable/c/9ecd238e8230e83a5c5436fd2261da4518f5c979; https://git.kernel.org/stable/c/f5b69101f956f5b89605a13cb15f093a7906f2a1
CVE: CVE-2025-68197
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix null pointer dereference in bnxt_bs_trace_check_wrap()

With older FW, we may get the ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCER
for FW trace data type that has not been initialized.  This will result
in a crash in bnxt_bs_trace_type_wrap().  Add a guard to check for a
valid magic_byte pointer before proceeding.
References: https://git.kernel.org/stable/c/689ae5ba31293eebb7f21c0ef8939468ac72b5ce; https://git.kernel.org/stable/c/ff02be05f78399c766be68ab0b2285ff90b2aaa8
CVE: CVE-2025-68198
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

crash: fix crashkernel resource shrink

When crashkernel is configured with a high reservation, shrinking its
value below the low crashkernel reservation causes two issues:

1. Invalid crashkernel resource objects
2. Kernel crash if crashkernel shrinking is done twice

For example, with crashkernel=200M,high, the kernel reserves 200MB of high
memory and some default low memory (say 256MB).  The reservation appears
as:

cat /proc/iomem | grep -i crash
af000000-beffffff : Crash kernel
433000000-43f7fffff : Crash kernel

If crashkernel is then shrunk to 50MB (echo 52428800 >
/sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:
af000000-beffffff : Crash kernel

Instead, it should show 50MB:
af000000-b21fffff : Crash kernel

Further shrinking crashkernel to 40MB causes a kernel crash with the
following trace (x86):

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
<snip...>
Call Trace: <TASK>
? __die_body.cold+0x19/0x27
? page_fault_oops+0x15a/0x2f0
? search_module_extables+0x19/0x60
? search_bpf_extables+0x5f/0x80
? exc_page_fault+0x7e/0x180
? asm_exc_page_fault+0x26/0x30
? __release_resource+0xd/0xb0
release_resource+0x26/0x40
__crash_shrink_memory+0xe5/0x110
crash_shrink_memory+0x12a/0x190
kexec_crash_size_store+0x41/0x80
kernfs_fop_write_iter+0x141/0x1f0
vfs_write+0x294/0x460
ksys_write+0x6d/0xf0
<snip...>

This happens because __crash_shrink_memory()/kernel/crash_core.c
incorrectly updates the crashk_res resource object even when
crashk_low_res should be updated.

Fix this by ensuring the correct crashkernel resource object is updated
when shrinking crashkernel memory.
References: https://git.kernel.org/stable/c/00fbff75c5acb4755f06f08bd1071879c63940c5; https://git.kernel.org/stable/c/a2bd247f8c6c5ac3f0ba823a2fffd77bb9cdf618; https://git.kernel.org/stable/c/f01f9c348d76d40bf104a94449e3ce4057fdefee
CVE: CVE-2025-68200
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Add bpf_prog_run_data_pointers()

syzbot found that cls_bpf_classify() is able to change
tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop().

WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline]
WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214

struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched:
Extend qdisc control block with tc control block"), which added a wrong
interaction with db58ba459202 ("bpf: wire in data and data_end for
cls_act_bpf").

drop_reason was added later.

Add bpf_prog_run_data_pointers() helper to save/restore the net_sched
storage colliding with BPF data_meta/data_end.
References: https://git.kernel.org/stable/c/4ef[PII_REDACTED]8932b9c320152b58274c05e5053; https://git.kernel.org/stable/c/5e149d8a8e732126fb6014efd60075cf63a73f91; https://git.kernel.org/stable/c/6392e5f4b1a3cce10e828309baf35d22abd3457d
CVE: CVE-2025-68201
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: remove two invalid BUG_ON()s

Those can be triggered trivially by userspace.
References: https://git.kernel.org/stable/c/5d55ed19d4190d2c210ac05ac7a53f800a8c6fe5; https://git.kernel.org/stable/c/a41bdba05899c7f455cd960ef0713acc335370dc; https://git.kernel.org/stable/c/eaf12bffd7f79f4d46ec028706f9d1a2d90f46fd