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

libceph: fix potential use-after-free in have_mon_and_osd_map()

The wait loop in __ceph_open_session() can race with the client
receiving a new monmap or osdmap shortly after the initial map is
received.  Both ceph_monc_handle_map() and handle_one_map() install
a new map immediately after freeing the old one

    kfree(monc->monmap);
    monc->monmap = monmap;

    ceph_osdmap_destroy(osdc->osdmap);
    osdc->osdmap = newmap;

under client->monc.mutex and client->osdc.lock respectively, but
because neither is taken in have_mon_and_osd_map() it's possible for
client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in

    client->monc.monmap && client->monc.monmap->epoch &&
        client->osdc.osdmap && client->osdc.osdmap->epoch;

condition to dereference an already freed map.  This happens to be
reproducible with generic/395 and generic/397 with KASAN enabled:

    BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
    Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
    CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
    ...
    Call Trace:
    <TASK>
    have_mon_and_osd_map+0x56/0x70
    ceph_open_session+0x182/0x290
    ceph_get_tree+0x333/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_after_hwframe+0x76/0x7e
    </TASK>

    Allocated by task 13305:
    ceph_osdmap_alloc+0x16/0x130
    ceph_osdc_init+0x27a/0x4c0
    ceph_create_client+0x153/0x190
    create_fs_client+0x50/0x2a0
    ceph_get_tree+0xff/0x680
    vfs_get_tree+0x49/0x180
    do_new_mount+0x1a3/0x2d0
    path_mount+0x6dd/0x730
    do_mount+0x99/0xe0
    __do_sys_mount+0x141/0x180
    do_syscall_64+0x9f/0x100
    entry_SYSCALL_64_after_hwframe+0x76/0x7e

    Freed by task 9475:
    kfree+0x212/0x290
    handle_one_map+0x23c/0x3b0
    ceph_osdc_handle_map+0x3c9/0x590
    mon_dispatch+0x655/0x6f0
    ceph_con_process_message+0xc3/0xe0
    ceph_con_v1_try_read+0x614/0x760
    ceph_con_workfn+0x2de/0x650
    process_one_work+0x486/0x7c0
    process_scheduled_works+0x73/0x90
    worker_thread+0x1c8/0x2a0
    kthread+0x2ec/0x300
    ret_from_fork+0x24/0x40
    ret_from_fork_asm+0x1a/0x30

Rewrite the wait loop to check the above condition directly with
client->monc.mutex and client->osdc.lock taken as appropriate.  While
at it, improve the timeout handling (previously mount_timeout could be
exceeded in case wait_event_interruptible_timeout() slept more than
once) and access client->auth_err under client->monc.mutex to match
how it's set in finish_auth().

monmap_show() and osdmap_show() now take the respective lock before
accessing the map as well.
References: https://git.kernel.org/stable/c/05ec43e9a9de67132dc8cd3b22afef001574947f; https://git.kernel.org/stable/c/076381c261374c587700b3accf410bdd2dba334e; https://git.kernel.org/stable/c/183ad6e3b651e8fb0b66d6a2678f4b80bfbba092
CVE: CVE-2025-68286
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check NULL before accessing

[WHAT]
IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomic
fails with NULL pointer dereference. This can be reproduced with
both an eDP panel and a DP monitors connected.

 BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted
6.16.0-99-custom #8 PREEMPT(voluntary)
 Hardware name: AMD ........
 RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu]
 Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49
 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30
 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02
 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292
 RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: ffffd0f3c2bd7668
 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000
 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760
 R10: ffffd0f3c2bd7820 R11: [PII_REDACTED] R12: ffff8b32494b8000
 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c
 FS:  000071f631b68700(0000) GS:ffff8b399f114000(0000)
knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: [PII_REDACTED] CR3: 00000001b8105000 CR4:[PII_REDACTED]f50ef0
 PKRU: 55555554
 Call Trace:
 <TASK>
 dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu]
 amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu]
 ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu]
 amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu]
 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400
 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30
 drm_crtc_get_last_vbltimestamp+0x55/0x90
 drm_crtc_next_vblank_start+0x45/0xa0
 drm_atomic_helper_wait_for_fences+0x81/0x1f0
 ...

(cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)
References: https://git.kernel.org/stable/c/09092269cb762378ca8b56024746b1a136761e0d; https://git.kernel.org/stable/c/109e9c92543f3105e8e1efd2c5e6b92ef55d5743; https://git.kernel.org/stable/c/3ce62c189693e8ed7b3abe551802bbc67f3ace54
CVE: CVE-2025-68287
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths

This patch addresses a race condition caused by unsynchronized
execution of multiple call paths invoking `dwc3_remove_requests()`,
leading to premature freeing of USB requests and subsequent crashes.

Three distinct execution paths interact with `dwc3_remove_requests()`:
Path 1:
Triggered via `dwc3_gadget_reset_interrupt()` during USB reset
handling. The call stack includes:
- `dwc3_ep0_reset_state()`
- `dwc3_ep0_stall_and_restart()`
- `dwc3_ep0_out_start()`
- `dwc3_remove_requests()`
- `dwc3_gadget_del_and_unmap_request()`

Path 2:
Also initiated from `dwc3_gadget_reset_interrupt()`, but through
`dwc3_stop_active_transfers()`. The call stack includes:
- `dwc3_stop_active_transfers()`
- `dwc3_remove_requests()`
- `dwc3_gadget_del_and_unmap_request()`

Path 3:
Occurs independently during `adb root` execution, which triggers
USB function unbind and bind operations. The sequence includes:
- `gserial_disconnect()`
- `usb_ep_disable()`
- `dwc3_gadget_ep_disable()`
- `dwc3_remove_requests()` with `-ESHUTDOWN` status

Path 3 operates asynchronously and lacks synchronization with Paths
1 and 2. When Path 3 completes, it disables endpoints and frees 'out'
requests. If Paths 1 or 2 are still processing these requests,
accessing freed memory leads to a crash due to use-after-free conditions.

To fix this added check for request completion and skip processing
if already completed and added the request status for ep0 while queue.
References: https://git.kernel.org/stable/c/467add9db13219101f14b6cc5477998b4aaa5fe2; https://git.kernel.org/stable/c/47de14d741cc4057046c9e2f33df1f7828254e6c; https://git.kernel.org/stable/c/67192e8cb7f941b5bba91e4bb290683576ce1607
CVE: CVE-2025-68288
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: storage: Fix memory leak in USB bulk transport

A kernel memory leak was identified by the 'ioctl_sg01' test from Linux
Test Project (LTP). The following bytes were mainly observed: 0x53425355.

When USB storage devices incorrectly skip the data phase with status data,
the code extracts/validates the CSW from the sg buffer, but fails to clear
it afterwards. This leaves status protocol data in srb's transfer buffer,
such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can
lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)
interfaces, such as the one seen here when the LTP test requested 512 KiB.

Fix the leak by zeroing the CSW data in srb's transfer buffer immediately
after the validation of devices that skip data phase.

Note: Differently from CVE-2[PII_REDACTED], which fixed a big leak by zero-
ing pages at allocation time, this leak occurs after allocation, when USB
protocol data is written to already-allocated sg pages.
References: https://git.kernel.org/stable/c/0f18eac44c5668204bf6eebb01ddb369ac56932b; https://git.kernel.org/stable/c/41e99fe[PII_REDACTED]b1058db71f0d241f8f0078c; https://git.kernel.org/stable/c/467fec3cefbeb9e3ea80f457da9a5666a71ca0d0
CVE: CVE-2025-68289
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_eem: Fix memory leak in eem_unwrap

The existing code did not handle the failure case of usb_ep_queue in the
command path, potentially leading to memory leaks.

Improve error handling to free all allocated resources on usb_ep_queue
failure. This patch continues to use goto logic for error handling, as the
existing error handling is complex and not easily adaptable to auto-cleanup
helpers.

kmemleak results:
  unreferenced object 0xffffff895a512300 (size 240):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      kmem_cache_alloc+0x1b4/0x358
      skb_clone+0x90/0xd8
      eem_unwrap+0x1cc/0x36c
  unreferenced object 0xffffff8a157f4000 (size 256):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      __kmem_cache_alloc_node+0x1b4/0x2dc
      kmalloc_trace+0x48/0x140
      dwc3_gadget_ep_alloc_request+0x58/0x11c
      usb_ep_alloc_request+0x40/0xe4
      eem_unwrap+0x204/0x36c
  unreferenced object 0xffffff8aadbaac00 (size 128):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      __kmem_cache_alloc_node+0x1b4/0x2dc
      __kmalloc+0x64/0x1a8
      eem_unwrap+0x218/0x36c
  unreferenced object 0xffffff89ccef3500 (size 64):
    backtrace:
      slab_post_alloc_hook+0xbc/0x3a4
      __kmem_cache_alloc_node+0x1b4/0x2dc
      kmalloc_trace+0x48/0x140
      eem_unwrap+0x238/0x36c
References: https://git.kernel.org/stable/c/0ac07e476944a5e4c2b8b087dd167dec248c1bdf; https://git.kernel.org/stable/c/0dea2e0069a7e9aa034696f8065945b7be6dd6b7; https://git.kernel.org/stable/c/41434488ca714ab15cb2a4d0378418d1be8052d2
CVE: CVE-2025-68290
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

most: usb: fix double free on late probe failure

The MOST subsystem has a non-standard registration function which frees
the interface on registration failures and on deregistration.

This unsurprisingly leads to bugs in the MOST drivers, and a couple of
recent changes turned a reference underflow and use-after-free in the
USB driver into several double free and a use-after-free on late probe
failures.
References: https://git.kernel.org/stable/c/0dece48660be16918ecf2dbdc7193e8be03e1693; https://git.kernel.org/stable/c/2274767dc02b756b25e3db1e31c0ed47c2a78442; https://git.kernel.org/stable/c/8d8ffefe3d5d8b7b73efb866db[PII_REDACTED]9c5c
CVE: CVE-2025-68292
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/memfd: fix information leak in hugetlb folios

When allocating hugetlb folios for memfd, three initialization steps are
missing:

1. Folios are not zeroed, leading to kernel memory disclosure to userspace
2. Folios are not marked uptodate before adding to page cache
3. hugetlb_fault_mutex is not taken before hugetlb_add_to_page_cache()

The memfd allocation path bypasses the normal page fault handler
(hugetlb_no_page) which would handle all of these initialization steps. 
This is problematic especially for udmabuf use cases where folios are
pinned and directly accessed by userspace via DMA.

Fix by matching the initialization pattern used in hugetlb_no_page():
- Zero the folio using folio_zero_user() which is optimized for huge pages
- Mark it uptodate with folio_mark_uptodate()
- Take hugetlb_fault_mutex before adding to page cache to prevent races

The folio_zero_user() change also fixes a potential security issue where
uninitialized kernel memory could be disclosed to userspace through read()
or mmap() operations on the memfd.
References: https://git.kernel.org/stable/c/50b4c1c28733a536d637d2f0401d60bcfef60ef2; https://git.kernel.org/stable/c/b09d7c4dc642849d9a96753233c6d00364017fd6; https://git.kernel.org/stable/c/de8798965fd0d9a6c47fc2ac57767ec32de12b49
CVE: CVE-2025-68293
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/huge_memory: fix NULL pointer deference when splitting folio

Commit c010d47f107f ("mm: thp: split huge page to any lower order pages")
introduced an early check on the folio's order via mapping->flags before
proceeding with the split work.

This check introduced a bug: for shmem folios in the swap cache and
truncated folios, the mapping pointer can be NULL.  Accessing
mapping->flags in this state leads directly to a NULL pointer dereference.

This commit fixes the issue by moving the check for mapping != NULL before
any attempt to access mapping->flags.
References: https://git.kernel.org/stable/c/592db83615a9f0164472ec789c2ed34ad35f732f; https://git.kernel.org/stable/c/cff47b9e39a6abf03dde5f4f156f841b0c54bba0; https://git.kernel.org/stable/c/d1b83fbacd4397a1d2f8c6b13427a8636ae2b307
CVE: CVE-2025-68294
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/net: ensure vectored buffer node import is tied to notification

When support for vectored registered buffers was added, the import
itself is using 'req' rather than the notification io_kiocb, sr->notif.
For non-vectored imports, sr->notif is correctly used. This is important
as the lifetime of the two may be different. Use the correct io_kiocb
for the vectored buffer import.
References: https://git.kernel.org/stable/c/14459281e027f23b70885c1cc1032a71c0efd8d7; https://git.kernel.org/stable/c/f6041803a831266a2a5a5b5af66f7de0845bcbf3
CVE: CVE-2025-68295
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix memory leak in cifs_construct_tcon()

When having a multiuser mount with domain= specified and using
cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,
so it needs to be freed before leaving cifs_construct_tcon().

This fixes the following memory leak reported by kmemleak:

  mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...
  su - testuser
  cifscreds add -d ZELDA -u testuser
  ...
  ls /mnt/1
  ...
  umount /mnt
  echo scan > /sys/kernel/debug/kmemleak
  cat /sys/kernel/debug/kmemleak
  unreferenced object 0xffff8881203c3f08 (size 8):
    comm "ls", pid 5060, jiffies[PII_REDACTED]
    hex dump (first 8 bytes):
      5a 45 4c 44 41 00 cc cc                          ZELDA...
    backtrace (crc d109a8cf):
      __kmalloc_node_track_caller_noprof+0x572/0x710
      kstrdup+0x3a/0x70
      cifs_sb_tlink+0x1209/0x1770 [cifs]
      cifs_get_fattr+0xe1/0xf50 [cifs]
      cifs_get_inode_info+0xb5/0x240 [cifs]
      cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]
      cifs_getattr+0x28e/0x450 [cifs]
      vfs_getattr_nosec+0x126/0x180
      vfs_statx+0xf6/0x220
      do_statx+0xab/0x110
      __x64_sys_statx+0xd5/0x130
      do_syscall_64+0xbb/0x380
      entry_SYSCALL_64_after_hwframe+0x77/0x7f
References: https://git.kernel.org/stable/c/3184b6a5a24ec9ee74087b2a550476f386df7dc2; https://git.kernel.org/stable/c/3dd546e867e94c2f954bca45a961b6104ba708b6; https://git.kernel.org/stable/c/a67e91d5f446e455dd9201cdd6e865f7078d251d
CVE: CVE-2025-68296
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup

Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB
access in fbcon_remap_all(). Without holding the console lock the call
races with switching outputs.

VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon
function uses struct fb_info.node, which is set by register_framebuffer().
As the fb-helper code currently sets up VGA switcheroo before registering
the framebuffer, the value of node is -1 and therefore not a legal value.
For example, fbcon uses the value within set_con2fb_map() [1] as an index
into an array.

Moving vga_switcheroo_client_fb_set() after register_framebuffer() can
result in VGA switching that does not switch fbcon correctly.

Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),
which already holds the console lock. Fbdev calls fbcon_fb_registered()
from within register_framebuffer(). Serializes the helper with VGA
switcheroo's call to fbcon_remap_all().

Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info
as parameter, it really only needs the contained fbcon state. Moving the
call to fbcon initialization is therefore cleaner than before. Only amdgpu,
i915, nouveau and radeon support vga_switcheroo. For all other drivers,
this change does nothing.
References: https://git.kernel.org/stable/c/05814c389b53d2f3a0b9eeb90ba7a05ba77c4c2a; https://git.kernel.org/stable/c/482330f8261b4bea8146d9bd69c1199e5dfcbb5c; https://git.kernel.org/stable/c/eb76d0f[PII_REDACTED]561010f24c277cc5b31d003
CVE: CVE-2025-68298
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref

In btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to:
  usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)

That function can return NULL in some cases. Even when it returns
NULL, though, we still go on to call btusb_mtk_claim_iso_intf().

As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks for
usb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf()
when `btmtk_data->isopkt_intf` is NULL will cause a crash because
we'll end up passing a bad pointer to device_lock(). Prior to that
commit we'd pass the NULL pointer directly to
usb_driver_claim_interface() which would detect it and return an
error, which was handled.

Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check
at the start of the function. This makes the code handle a NULL
`btmtk_data->isopkt_intf` the same way it did before the problematic
commit (just with a slight change to the error message printed).
References: https://git.kernel.org/stable/c/2fa09fe98ca3b114d66285f65f7e108fea131815; https://git.kernel.org/stable/c/c3b990e0b23068da65f0004cd38ee31f43f36460; https://git.kernel.org/stable/c/c884a0b27b4586e607431d86a1aa0bb4fb39169c
CVE: CVE-2025-68299
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

afs: Fix delayed allocation of a cell's anonymous key

The allocation of a cell's anonymous key is done in a background thread
along with other cell setup such as doing a DNS upcall.  In the reported
bug, this is triggered by afs_parse_source() parsing the device name given
to mount() and calling afs_lookup_cell() with the name of the cell.

The normal key lookup then tries to use the key description on the
anonymous authentication key as the reference for request_key() - but it
may not yet be set and so an oops can happen.

This has been made more likely to happen by the fix for dynamic lookup
failure.

Fix this by firstly allocating a reference name and attaching it to the
afs_cell record when the record is created.  It can share the memory
allocation with the cell name (unfortunately it can't just overlap the cell
name by prepending it with "afs@" as the cell name already has a '.'
prepended for other purposes).  This reference name is then passed to
request_key().

Secondly, the anon key is now allocated on demand at the point a key is
requested in afs_request_key() if it is not already allocated.  A mutex is
used to prevent multiple allocation for a cell.

Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't
yet allocated (if we need it) and then the caller can return -ECHILD to
drop out of RCU-mode and afs_request_key() can be called.

Note that the anonymous key is kind of necessary to make the key lookup
cache work as that doesn't currently cache a negative lookup, but it's
probably worth some investigation to see if NULL can be used instead.
References: https://git.kernel.org/stable/c/5613bde937dfac6725e9c3fc766b9d6b8481e55b; https://git.kernel.org/stable/c/d27c71257825dced46104eefe42e4d9964bd032e
CVE: CVE-2025-68300
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/namespace: fix reference leak in grab_requested_mnt_ns

lookup_mnt_ns() already takes a reference on mnt_ns.
grab_requested_mnt_ns() doesn't need to take an extra reference.
References: https://git.kernel.org/stable/c/4a16b2a0c1f033f95f5d0b98b9e40e8bf7c4c2c5; https://git.kernel.org/stable/c/7b6dcd9bfd869eee7693e45b1817dac8c56e5f86; https://git.kernel.org/stable/c/fe256e59b8e7f126b2464ee32bd9fee131f0a883
CVE: CVE-2025-68301
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: atlantic: fix fragment overflow handling in RX path

The atlantic driver can receive packets with more than MAX_SKB_FRAGS (17)
fragments when handling large multi-descriptor packets. This causes an
out-of-bounds write in skb_add_rx_frag_netmem() leading to kernel panic.

The issue occurs because the driver doesn't check the total number of
fragments before calling skb_add_rx_frag(). When a packet requires more
than MAX_SKB_FRAGS fragments, the fragment index exceeds the array bounds.

Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,
then all fragments are accounted for. And reusing the existing check to
prevent the overflow earlier in the code path.

This crash occurred in production with an Aquantia AQC113 10G NIC.

Stack trace from production environment:
```
RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0
Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89
ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90
c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48
89 fa 83
RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287
RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:
fffffffe0a0c8000
RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:[PII_REDACTED]037a40
RBP: [PII_REDACTED] R08: [PII_REDACTED] R09:
[PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12:
ffffa9bec02a8e24
R13: ffff925ad8615570 R14: [PII_REDACTED] R15:
ffff925b22e80a00
FS: [PII_REDACTED](0000)
GS:ffff925e47880000(0000) knlGS:[PII_REDACTED]
CS: 0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: ffff9258ea95baf0 CR3: [PII_REDACTED] CR4:[PII_REDACTED]f72ef0
PKRU: 55555554
Call Trace:
<IRQ>
aq_ring_rx_clean+0x175/0xe60 [atlantic]
? aq_ring_rx_clean+0x14d/0xe60 [atlantic]
? aq_ring_tx_clean+0xdf/0x190 [atlantic]
? kmem_cache_free+0x348/0x450
? aq_vec_poll+0x81/0x1d0 [atlantic]
? __napi_poll+0x28/0x1c0
? net_rx_action+0x337/0x420
```

Changes in v4:
- Add Fixes: tag to satisfy patch validation requirements.

Changes in v3:
- Fix by assuming there will be an extra frag if buff->len > AQ_CFG_RX_HDR_SIZE,
  then all fragments are accounted for.
References: https://git.kernel.org/stable/c/34147477eeab24077fcfe9649e282849347d760c; https://git.kernel.org/stable/c/3be37c3c96b16462394fcb8e15e757c691377038; https://git.kernel.org/stable/c/3fd2105e1b7e041cc24be151c9a31a14d5fc50ab
CVE: CVE-2025-68302
Published: 2025-12-16
Description: In the Linux kernel, the following vulnerability has been resolved:

net: sxgbe: fix potential NULL dereference in sxgbe_rx()

Currently, when skb is null, the driver prints an error and then
dereferences skb on the next line.

To fix this, let's add a 'break' after the error message to switch
to sxgbe_rx_refill(), which is similar to the approach taken by the
other drivers in this particular case, e.g. calxeda with xgmac_rx().

Found during a code review.
References: https://git.kernel.org/stable/c/18ef3ad1bb57dcf1a9ee61736039aedccf670b21; https://git.kernel.org/stable/c/45b5b4ddb8d6bea5fc1625ff6f163bbb125d49cc; https://git.kernel.org/stable/c/46e[PII_REDACTED]a2ca791140feab18ce1fc1a3c86