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

crypto: safexcel - Cleanup ring IRQ workqueues on load failure

A failure loading the safexcel driver results in the following warning
on boot, because the IRQ affinity has not been correctly cleaned up.
Ensure we clean up the affinity and workqueues on a failure to load the
driver.

crypto-safexcel: probe of f2800000.crypto failed with error -2
------------[ cut here ]------------
WARNING: CPU: 1 PID: 232 at kernel/irq/manage.c:1913 free_irq+0x300/0x340
Modules linked in: hwmon mdio_i2c crypto_safexcel(+) md5 sha256_generic libsha256 authenc libdes omap_rng rng_core nft_masq nft_nat nft_chain_nat nf_nat nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink fuse autofs4
CPU: 1 PID: 232 Comm: systemd-udevd Tainted: G        W          6.1.6-00002-g9d[PII_REDACTED] #3
Hardware name: MikroTik RB5009 (DT)
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : free_irq+0x300/0x340
lr : free_irq+0x2e0/0x340
sp : ffff800008fa3890
x29: ffff800008fa3890 x28: [PII_REDACTED] x27: [PII_REDACTED]
x26: ffff8000008e6dc0 x25: ffff000009034cac x24: ffff000009034d50
x23: [PII_REDACTED] x22:[PII_REDACTED]00004a x21: ffff0000093e0d80
x20: ffff000009034c00 x19: ffff00000615fc00 x18: [PII_REDACTED]
x17: [PII_REDACTED] x16: [PII_REDACTED] x15: 000075f5c1584c5e
x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
x11: ffff000000579b60 x10: ffff000000579b62 x9 : ffff800008bbe370
x8 : ffff000000579dd0 x7 : [PII_REDACTED] x6 : ffff000000579e18
x5 : ffff000000579da8 x4 : ffff800008ca0000 x3 : ffff800008ca0188
x2 : [PII_REDACTED] x1 : ffff000009034c00 x0 : ffff8000087eadf0
Call trace:
 free_irq+0x300/0x340
 devm_irq_release+0x14/0x20
 devres_release_all+0xa0/0x100
 device_unbind_cleanup+0x14/0x60
 really_probe+0x198/0x2d4
 __driver_probe_device+0x74/0xdc
 driver_probe_device+0x3c/0x110
 __driver_attach+0x8c/0x190
 bus_for_each_dev+0x6c/0xc0
 driver_attach+0x20/0x30
 bus_add_driver+0x148/0x1fc
 driver_register+0x74/0x120
 __platform_driver_register+0x24/0x30
 safexcel_init+0x48/0x1000 [crypto_safexcel]
 do_one_initcall+0x4c/0x1b0
 do_init_module+0x44/0x1cc
 load_module+0x1724/0x1be4
 __do_sys_finit_module+0xbc/0x110
 __arm64_sys_finit_module+0x1c/0x24
 invoke_syscall+0x44/0x110
 el0_svc_common.constprop.0+0xc0/0xe0
 do_el0_svc+0x20/0x80
 el0_svc+0x14/0x4c
 el0t_64_sync_handler+0xb0/0xb4
 el0t_64_sync+0x148/0x14c
---[ end trace [PII_REDACTED] ]---
References: https://git.kernel.org/stable/c/09e177d6f7edd0873a63f51abe914902ec0f4400; https://git.kernel.org/stable/c/0a89d4a075524cf1f865cfdbb9cf38ab8e3e5409; https://git.kernel.org/stable/c/162f9daf0c22480f88b24fd46d16abae46c10fce
CVE: CVE-2023-54128
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: drop peer group ids under namespace lock

When cleaning up peer group ids in the failure path we need to make sure
to hold on to the namespace lock. Otherwise another thread might just
turn the mount from a shared into a non-shared mount concurrently.
References: https://git.kernel.org/stable/c/0af8fae81d8b7f1beddc17c5d4cfa[PII_REDACTED]8; https://git.kernel.org/stable/c/65c324d3f35c05e37afec39ac80743583fdcc96c; https://git.kernel.org/stable/c/cb2239c198ad9fbd5aced22cf93e45562da781eb
CVE: CVE-2023-54129
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Add validation for lmac type

Upon physical link change, firmware reports to the kernel about the
change along with the details like speed, lmac_type_id, etc.
Kernel derives lmac_type based on lmac_type_id received from firmware.

In a few scenarios, firmware returns an invalid lmac_type_id, which
is resulting in below kernel panic. This patch adds the missing
validation of the lmac_type_id field.

Internal error: Oops: 96000005 [#1] PREEMPT SMP
[   35.321595] Modules linked in:
[   35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted
5.4.210-g2e3169d8e1bc-dirty #17
[   35.337014] Hardware name: Marvell CN103XX board (DT)
[   35.344297] Workqueue: events work_for_cpu_fn
[   35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO)
[   35.360267] pc : strncpy+0x10/0x30
[   35.366595] lr : cgx_link_change_handler+0x90/0x180
References: https://git.kernel.org/stable/c/5c0268b141ad612b6fca13d3a66cfda111716dbb; https://git.kernel.org/stable/c/83a7f27c5b94e43f29f8216a[PII_REDACTED]9aa61e; https://git.kernel.org/stable/c/afd7660c766c4d317feae004e5cd829390bbc4b0
CVE: CVE-2023-54130
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handling

Commit 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check") fixed
a build warning by turning a comment into a WARN_ON(), but it turns out
that syzbot then complains because it can trigger said warning with a
corrupted hfs image.

The warning actually does warn about a bad situation, but we are much
better off just handling it as the error it is.  So rather than warn
about us doing bad things, stop doing the bad things and return -EIO.

While at it, also fix a memory leak that was introduced by an earlier
fix for a similar syzbot warning situation, and add a check for one case
that historically wasn't handled at all (ie neither comment nor
subsequent WARN_ON).
References: https://git.kernel.org/stable/c/45917be9f0af339a45b4619f31c902d37b8aed59; https://git.kernel.org/stable/c/82725be426bce0a425cc5e26fbad61ffd29cff03; https://git.kernel.org/stable/c/90e019006644dad35862cb4aa270f561b0732066
CVE: CVE-2023-54131
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rt2x00: Fix memory leak when handling surveys

When removing a rt2x00 device, its associated channel surveys
are not freed, causing a memory leak observable with kmemleak:

unreferenced object 0xffff9620f0881a00 (size 512):
  comm "systemd-udevd", pid 2290, jiffies[PII_REDACTED] (age 33.768s)
  hex dump (first 32 bytes):
    70 44 12 00 00 00 00 00 92 8a 00 00 00 00 00 00  pD..............
    00 00 00 00 00 00 00 00 ab 87 01 00 00 00 00 00  ................
  backtrace:
    [<ffffffffb0ed858b>] __kmalloc+0x4b/0x130
    [<ffffffffc1b0f29b>] rt2800_probe_hw+0xc2b/0x1380 [rt2800lib]
    [<ffffffffc1a9496e>] rt2800usb_probe_hw+0xe/0x60 [rt2800usb]
    [<ffffffffc1ae491a>] rt2x00lib_probe_dev+0x21a/0x7d0 [rt2x00lib]
    [<ffffffffc1b3b83e>] rt2x00usb_probe+0x1be/0x980 [rt2x00usb]
    [<ffffffffc05981e2>] usb_probe_interface+0xe2/0x310 [usbcore]
    [<ffffffffb13be2d5>] really_probe+0x1a5/0x410
    [<ffffffffb13be5c8>] __driver_probe_device+0x78/0x180
    [<ffffffffb13be6fe>] driver_probe_device+0x1e/0x90
    [<ffffffffb13be972>] __driver_attach+0xd2/0x1c0
    [<ffffffffb13bbc57>] bus_for_each_dev+0x77/0xd0
    [<ffffffffb13bd2a2>] bus_add_driver+0x112/0x210
    [<ffffffffb13bfc6c>] driver_register+0x5c/0x120
    [<ffffffffc0596ae8>] usb_register_driver+0x88/0x150 [usbcore]
    [<ffffffffb0c011c4>] do_one_initcall+0x44/0x220
    [<ffffffffb0d6134c>] do_init_module+0x4c/0x220

Fix this by freeing the channel surveys on device removal.

Tested with a RT3070 based USB wireless adapter.
References: https://git.kernel.org/stable/c/0354bce76ed1d775904acdb4cc0bf88c5b9b5b9f; https://git.kernel.org/stable/c/494064ffd60d044c097d514917c40913d1affbca; https://git.kernel.org/stable/c/bea3f8aa999318bdffa2d17753e492f76904f0ce
CVE: CVE-2023-54132
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: stop parsing non-compact HEAD index if clusterofs is invalid

Syzbot generated a crafted image [1] with a non-compact HEAD index of
clusterofs 33024 while valid numbers should be 0 ~ lclustersize-1,
which causes the following unexpected behavior as below:

 BUG: unable to handle page fault for address: fffff52101a3fff9
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 23ffed067 P4D 23ffed067 PUD 0
 Oops: 0000 [#1] PREEMPT SMP KASAN
 CPU: 1 PID: 4398 Comm: kworker/u5:1 Not tainted 6.3.0-rc6-syzkaller-g09a9639e56c0 #0
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
 Workqueue: erofs_worker z_erofs_decompressqueue_work
 RIP: 0010:z_erofs_decompress_queue+0xb7e/0x2b40
 ...
 Call Trace:
  <TASK>
  z_erofs_decompressqueue_work+0x99/0xe0
  process_one_work+0x8f6/0x1170
  worker_thread+0xa63/0x1210
  kthread+0x270/0x300
  ret_from_fork+0x1f/0x30

Note that normal images or images using compact indexes are not
impacted.  Let's fix this now.

[1] https://lore.kernel.org/r/[PII_REDACTED]00ec75b005ee97fbaa@google.com
References: https://git.kernel.org/stable/c/060fecf1114ff9fcfe87953fe8c4fc[PII_REDACTED]; https://git.kernel.org/stable/c/7a4579cd6e4936de107c82499c3c9ee11b63401e; https://git.kernel.org/stable/c/7ee7a86e28ce9ead7112286c388df8d254c373c6
CVE: CVE-2023-54133
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

nfp: clean mc addresses in application firmware when closing port

When moving devices from one namespace to another, mc addresses are
cleaned in software while not removed from application firmware. Thus
the mc addresses are remained and will cause resource leak.

Now use `__dev_mc_unsync` to clean mc addresses when closing port.
References: https://git.kernel.org/stable/c/c427221733d49fd1e1b79b4a86746acf3ef660e7; https://git.kernel.org/stable/c/cc7eab25b1cf3f9594fe61142d3523ce4d14a788
CVE: CVE-2023-54135
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()

Check the write offset end bounds before using it as the offset into the
pivot array.  This avoids a possible out-of-bounds access on the pivot
array if the write extends to the last slot in the node, in which case the
node maximum should be used as the end pivot.

akpm: this doesn't affect any current callers, but new users of mapletree
may encounter this problem if backported into earlier kernels, so let's
fix it in -stable kernels in case of this.
References: https://git.kernel.org/stable/c/4e2ad53ababeaac44d[PII_REDACTED]4abfe783960c; https://git.kernel.org/stable/c/cd00dd2585c4158e81fdfac0bbcc0446afbad26d; https://git.kernel.org/stable/c/dc4751bd4aba01ccfc02f91adfeee0ba4cda405c
CVE: CVE-2023-54136
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

serial: sprd: Fix DMA buffer leak issue

Release DMA buffer when _probe() returns failure to avoid memory leak.
References: https://git.kernel.org/stable/c/0237f913694d57bcd7e0e7ae6f255b648a1c42a7; https://git.kernel.org/stable/c/4ee715e54e255b1be65722f715fca939d5c2ca7a; https://git.kernel.org/stable/c/6d209ed70f9c388727995aaece1f930fe63d402b
CVE: CVE-2023-54137
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

vfio/type1: fix cap_migration information leak

Fix an information leak where an uninitialized hole in struct
vfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.

The definition of struct vfio_iommu_type1_info_cap_migration contains a hole as
shown in this pahole(1) output:

  struct vfio_iommu_type1_info_cap_migration {
          struct vfio_info_cap_header header;              /*     0     8 */
          __u32                      flags;                /*     8     4 */

          /* XXX 4 bytes hole, try to pack */

          __u64                      pgsize_bitmap;        /*    16     8 */
          __u64                      max_dirty_bitmap_size; /*    24     8 */

          /* size: 32, cachelines: 1, members: 4 */
          /* sum members: 28, holes: 1, sum holes: 4 */
          /* last cacheline: 32 bytes */
  };

The cap_mig variable is filled in without initializing the hole:

  static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu,
                         struct vfio_info_cap *caps)
  {
      struct vfio_iommu_type1_info_cap_migration cap_mig;

      cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION;
      cap_mig.header.version = 1;

      cap_mig.flags = 0;
      /* support minimum pgsize */
      cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap);
      cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX;

      return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig));
  }

The structure is then copied to a temporary location on the heap. At this point
it's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspace
later:

  int vfio_info_add_capability(struct vfio_info_cap *caps,
                   struct vfio_info_cap_header *cap, size_t size)
  {
      struct vfio_info_cap_header *header;

      header = vfio_info_cap_add(caps, size, cap->id, cap->version);
      if (IS_ERR(header))
          return PTR_ERR(header);

      memcpy(header + 1, cap + 1, size - sizeof(*header));

      return 0;
  }

This issue was found by code inspection.
References: https://git.kernel.org/stable/c/13fd667db999bffb557c5de7adb3c14f1713dd51; https://git.kernel.org/stable/c/1b5feb8497cdb5b9962db2700814bffbc030fb4a; https://git.kernel.org/stable/c/ad83d83dd891244de0d07678b257dc976db7c132
CVE: CVE-2023-54138
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: fix NULL-deref on irq uninstall

In case of early initialisation errors and on platforms that do not use
the DPU controller, the deinitilisation code can be called with the kms
pointer set to NULL.

Patchwork: https://patchwork.freedesktop.org/patch/525104/
References: https://git.kernel.org/stable/c/72092e34742e8b34accdadfa7bd9a13cf255a531; https://git.kernel.org/stable/c/bafa985acff9b0ed53957beff33c18be08d6b9a6; https://git.kernel.org/stable/c/cd459c005de3e2b855a8cc7768e633ce9d018e9f
CVE: CVE-2023-54139
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing/user_events: Ensure write index cannot be negative

The write index indicates which event the data is for and accesses a
per-file array. The index is passed by user processes during write()
calls as the first 4 bytes. Ensure that it cannot be negative by
returning -EINVAL to prevent out of bounds accesses.

Update ftrace self-test to ensure this occurs properly.
References: https://git.kernel.org/stable/c/0489c2b2c3104b89f078dbcec8c744dfc157d3e9; https://git.kernel.org/stable/c/4fe46b5adf18e3dc606e62c9e6a0413398a17572; https://git.kernel.org/stable/c/cd98c93286a30cc4588dfd02453bec63c2f4acf4
CVE: CVE-2023-54140
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse

A syzbot stress test using a corrupted disk image reported that
mark_buffer_dirty() called from __nilfs_mark_inode_dirty() or
nilfs_palloc_commit_alloc_entry() may output a kernel warning, and can
panic if the kernel is booted with panic_on_warn.

This is because nilfs2 keeps buffer pointers in local structures for some
metadata and reuses them, but such buffers may be forcibly discarded by
nilfs_clear_dirty_page() in some critical situations.

This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: do
not write dirty data after degenerating to read-only"), but the issue has
potentially existed before.

Fix this issue by checking the uptodate flag when attempting to reuse an
internally held buffer, and reloading the metadata instead of reusing the
buffer if the flag was lost.
References: https://git.kernel.org/stable/c/46c11be2dca295742a5508ea910a77f7733fb7f4; https://git.kernel.org/stable/c/[PII_REDACTED]94f261e98920f[PII_REDACTED]df36f07; https://git.kernel.org/stable/c/4da07e958bfda2d69d83db105780e8916e3ac02e
CVE: CVE-2023-54141
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: Add missing hw_ops->get_ring_selector() for IPQ5018

During sending data after clients connected, hw_ops->get_ring_selector()
will be called. But for IPQ5018, this member isn't set, and the
following NULL pointer exception will be occurred:

	[   38.840478] 8<--- cut here ---
	[   38.840517] Unable to handle kernel NULL pointer dereference at virtual address 00000000
	...
	[   38.923161] PC is at 0x0
	[   38.927930] LR is at ath11k_dp_tx+0x70/0x730 [ath11k]
	...
	[   39.063264] Process hostapd (pid: 1034, stack limit = 0x801ceb3d)
	[   39.068994] Stack: (0x856a9a68 to 0x856aa000)
	...
	[   39.438467] [<7f323804>] (ath11k_dp_tx [ath11k]) from [<7f314e6c>] (ath11k_mac_op_tx+0x80/0x190 [ath11k])
	[   39.446607] [<7f314e6c>] (ath11k_mac_op_tx [ath11k]) from [<7f17dbe0>] (ieee80211_handle_wake_tx_queue+0x7c/0xc0 [mac80211])
	[   39.456162] [<7f17dbe0>] (ieee80211_handle_wake_tx_queue [mac80211]) from [<7f174450>] (ieee80211_probereq_get+0x584/0x704 [mac80211])
	[   39.467443] [<7f174450>] (ieee80211_probereq_get [mac80211]) from [<7f178c40>] (ieee80211_tx_prepare_skb+0x1f8/0x248 [mac80211])
	[   39.479334] [<7f178c40>] (ieee80211_tx_prepare_skb [mac80211]) from [<7f179e28>] (__ieee80211_subif_start_xmit+0x32c/0x3d4 [mac80211])
	[   39.491053] [<7f179e28>] (__ieee80211_subif_start_xmit [mac80211]) from [<7f17af08>] (ieee80211_tx_control_port+0x19c/0x288 [mac80211])
	[   39.502946] [<7f17af08>] (ieee80211_tx_control_port [mac80211]) from [<7f0fc704>] (nl80211_tx_control_port+0x174/0x1d4 [cfg80211])
	[   39.515017] [<7f0fc704>] (nl80211_tx_control_port [cfg80211]) from [<808ceac4>] (genl_rcv_msg+0x154/0x340)
	[   39.526814] [<808ceac4>] (genl_rcv_msg) from [<808cdb74>] (netlink_rcv_skb+0xb8/0x11c)
	[   39.536446] [<808cdb74>] (netlink_rcv_skb) from [<808ce1d0>] (genl_rcv+0x28/0x34)
	[   39.544344] [<808ce1d0>] (genl_rcv) from [<808cd234>] (netlink_unicast+0x174/0x274)
	[   39.551895] [<808cd234>] (netlink_unicast) from [<808cd510>] (netlink_sendmsg+0x1dc/0x440)
	[   39.559362] [<808cd510>] (netlink_sendmsg) from [<808596e0>] (____sys_sendmsg+0x1a8/0x1fc)
	[   39.567697] [<808596e0>] (____sys_sendmsg) from [<8085b1a8>] (___sys_sendmsg+0xa4/0xdc)
	[   39.575941] [<8085b1a8>] (___sys_sendmsg) from [<8085b310>] (sys_sendmsg+0x44/0x74)
	[   39.583841] [<8085b310>] (sys_sendmsg) from [<80300060>] (ret_fast_syscall+0x0/0x40)
	...
	[   39.620734] Code: bad PC value
	[   39.625869] ---[ end trace 8aef983ad3cbc032 ]---
References: https://git.kernel.org/stable/c/c36289e3c5e83286974ef68c20c821fd5b63801c; https://git.kernel.org/stable/c/ce282d8de71f07f0056ea[PII_REDACTED]52c65f552; https://git.kernel.org/stable/c/d1992d72a359732f143cc962917104d193705da7
CVE: CVE-2023-54143
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init()

If we encounter any error in the vdec_msg_queue_init() then we need
to set "msg_queue->wdma_addr.size = 0;".  Normally, this is done
inside the vdec_msg_queue_deinit() function.  However, if the
first call to allocate &msg_queue->wdma_addr fails, then the
vdec_msg_queue_deinit() function is a no-op.  For that situation, just
set the size to zero explicitly and return.

There were two other error paths which did not clean up before returning.
Change those error paths to goto mem_alloc_err.
References: https://git.kernel.org/stable/c/451dc187cadd47771e5d9434fe220fad7be84057; https://git.kernel.org/stable/c/858322c409e0aba8f70810d23f35c482744f007c; https://git.kernel.org/stable/c/b7dbc27301f560c3b915235c53383155b3512083
CVE: CVE-2023-54144
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix kernel warning during topology setup

This patch fixes the following kernel warning seen during
driver load by correctly initializing the p2plink attr before
creating the sysfs file:

[  +0.002865] ------------[ cut here ]------------
[  +0.002327] kobject: '(null)'[PII_REDACTED]260cfb): is not initialized, yet kobject_put() is being called.
[  +0.004780] WARNING: CPU: 32 PID: 1006 at lib/kobject.c:718 kobject_put+0xaa/0x1c0
[  +0.001361] Call Trace:
[  +0.001234]  <TASK>
[  +0.001067]  kfd_remove_sysfs_node_entry+0x24a/0x2d0 [amdgpu]
[  +0.003147]  kfd_topology_update_sysfs+0x3d/0x750 [amdgpu]
[  +0.002890]  kfd_topology_add_device+0xbd7/0xc70 [amdgpu]
[  +0.002844]  ? lock_release+0x13c/0x2e0
[  +0.001936]  ? smu_cmn_send_smc_msg_with_param+0x1e8/0x2d0 [amdgpu]
[  +0.003313]  ? amdgpu_dpm_get_mclk+0x54/0x60 [amdgpu]
[  +0.002703]  kgd2kfd_device_init.cold+0x39f/0x4ed [amdgpu]
[  +0.002930]  amdgpu_amdkfd_device_init+0x13d/0x1f0 [amdgpu]
[  +0.002944]  amdgpu_device_init.cold+0x1464/0x17b4 [amdgpu]
[  +0.002970]  ? pci_bus_read_config_word+0x43/0x80
[  +0.002380]  amdgpu_driver_load_kms+0x15/0x100 [amdgpu]
[  +0.002744]  amdgpu_pci_probe+0x147/0x370 [amdgpu]
[  +0.002522]  local_pci_probe+0x40/0x80
[  +0.001896]  work_for_cpu_fn+0x10/0x20
[  +0.001892]  process_one_work+0x26e/0x5a0
[  +0.002029]  worker_thread+0x1fd/0x3e0
[  +0.001890]  ? process_one_work+0x5a0/0x5a0
[  +0.002115]  kthread+0xea/0x110
[  +0.001618]  ? kthread_complete_and_exit+0x20/0x20
[  +0.002422]  ret_from_fork+0x1f/0x30
[  +0.001808]  </TASK>
[  +0.001103] irq event stamp: 59837
[  +0.001718] hardirqs last  enabled at (59849): [<ffffffffb30fab12>] __up_console_sem+0x52/0x60
[  +0.004414] hardirqs last disabled at (59860): [<ffffffffb30faaf7>] __up_console_sem+0x37/0x60
[  +0.004414] softirqs last  enabled at (59654): [<ffffffffb307d9c7>] irq_exit_rcu+0xd7/0x130
[  +0.004205] softirqs last disabled at (59649): [<ffffffffb307d9c7>] irq_exit_rcu+0xd7/0x130
[  +0.004203] ---[ end trace [PII_REDACTED] ]---
References: https://git.kernel.org/stable/c/2d5a6742a242091292cc0a2b607be701a45d0c4e; https://git.kernel.org/stable/c/306888b1246bf44e703b6f1ccc746c2746c1a981; https://git.kernel.org/stable/c/cf97eb7e47d4671084c7e114c5d88a3d0540ecbd
CVE: CVE-2023-54145
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log

It's trivial for user to trigger "verifier log line truncated" warning,
as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at
least two pieces of user-provided information that can be output through
this buffer, and both can be arbitrarily sized by user:
  - BTF names;
  - BTF.ext source code lines strings.

Verifier log buffer should be properly sized for typical verifier state
output. But it's sort-of expected that this buffer won't be long enough
in some circumstances. So let's drop the check. In any case code will
work correctly, at worst truncating a part of a single line output.
References: https://git.kernel.org/stable/c/40c88c429a598006f91ad7a2b89856cd50b3a008; https://git.kernel.org/stable/c/926a175026fed5d534f587ea4ec3ec49265cd3c5; https://git.kernel.org/stable/c/cff36398bd4c7d322d424433db437f3c3391c491
CVE: CVE-2023-54146
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/kexec: Fix double-free of elf header buffer

After

  b3e34a47f989 ("x86/kexec: fix memory leak of elf header buffer"),

freeing image->elf_headers in the error path of crash_load_segments()
is not needed because kimage_file_post_load_cleanup() will take
care of that later. And not clearing it could result in a double-free.

Drop the superfluous vfree() call at the error path of
crash_load_segments().
References: https://git.kernel.org/stable/c/4c71a552b97fb4f46eb300224434fe56fcf4f254; https://git.kernel.org/stable/c/554a880a1fff46dd5a355dec21cd77d542a0ddf2; https://git.kernel.org/stable/c/5bd3c7abeb69fb4133418b846a1c6dc11313d6f0