deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38310
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

seg6: Fix validation of nexthop addresses

The kernel currently validates that the length of the provided nexthop
address does not exceed the specified length. This can lead to the
kernel reading uninitialized memory if user space provided a shorter
length than the specified one.

Fix by validating that the provided length exactly matches the specified
one.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/668923c474608dd9ebce0fbcc41bd8a27aa73dd6; https://git.kernel.org/stable/c/7632fedb266d93ed0ed9f487133e6c6314a9b2d1; https://git.kernel.org/stable/c/cd4cd09810211fa23609c5c1018352e9e1cd8e5a
CVE: CVE-2025-38311
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

iavf: get rid of the crit lock

Get rid of the crit lock.
That frees us from the error prone logic of try_locks.

Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were
protected by it already - replace crit lock by netdev lock when it was not
the case.

Lockdep reports that we should cancel the work under crit_lock [splat1],
and that was the scheme we have mostly followed since [1] by Slawomir.
But when that is done we still got into deadlocks [splat2]. So instead
we should look at the bigger problem, namely "weird locking/scheduling"
of the iavf. The first step to fix that is to remove the crit lock.
I will followup with a -next series that simplifies scheduling/tasks.

Cancel the work without netdev lock (weird unlock+lock scheme),
to fix the [splat2] (which would be totally ugly if we would kept
the crit lock).

Extend protected part of iavf_watchdog_task() to include scheduling
more work.

Note that the removed comment in iavf_reset_task() was misplaced,
it belonged to inside of the removed if condition, so it's gone now.

[splat1] - w/o this patch - The deadlock during VF removal:
     WARNING: possible circular locking dependency detected
     sh/3825 is trying to acquire lock:
      ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470
          but task is already holding lock:
      (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]
          which lock already depends on the new lock.

[splat2] - when cancelling work under crit lock, w/o this series,
	   see [2] for the band aid attempt
    WARNING: possible circular locking dependency detected
    sh/3550 is trying to acquire lock:
    ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90
        but task is already holding lock:
    (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]
        which lock already depends on the new lock.

[1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation")
[2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/120f28a6f314fef7f282c99f196923fe44081cad; https://git.kernel.org/stable/c/620ab4d6215de0b25227f9fff1a8c7fb66837cb8
CVE: CVE-2025-38312
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()

In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,
cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's
then passed to fb_cvt_hperiod(), where it's used as a divider -- division
by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to
avoid such overflow...

Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/2d63433e8eaa3c91b2948190e395bc67009db0d9; https://git.kernel.org/stable/c/3f6dae09fc8c306eb70fdfef70726e1f154e173a; https://git.kernel.org/stable/c/53784073cbad18f75583fd3da9ffdfc4d1f05405
CVE: CVE-2025-38313
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

bus: fsl-mc: fix double-free on mc_dev

The blamed commit tried to simplify how the deallocations are done but,
in the process, introduced a double-free on the mc_dev variable.

In case the MC device is a DPRC, a new mc_bus is allocated and the
mc_dev variable is just a reference to one of its fields. In this
circumstance, on the error path only the mc_bus should be freed.

This commit introduces back the following checkpatch warning which is a
false-positive.

WARNING: kfree(NULL) is safe and this check is probably not required
+       if (mc_bus)
+               kfree(mc_bus);
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/12e4431e[PII_REDACTED]936820bd39df9e1ee26d2e; https://git.kernel.org/stable/c/1d5baab39e5b09a76870b345cdee7933871b881f; https://git.kernel.org/stable/c/3135e03a92f6b5259d0a7f25f728e9e7866ede3f
CVE: CVE-2025-38314
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-pci: Fix result size returned for the admin command completion

The result size returned by virtio_pci_admin_dev_parts_get() is 8 bytes
larger than the actual result data size. This occurs because the
result_sg_size field of the command is filled with the result length
from virtqueue_get_buf(), which includes both the data size and an
additional 8 bytes of status.

This oversized result size causes two issues:
1. The state transferred to the destination includes 8 bytes of extra
   data at the end.
2. The allocated buffer in the kernel may be smaller than the returned
   size, leading to failures when reading beyond the allocated size.

The commit fixes this by subtracting the status size from the result of
virtqueue_get_buf().

This fix has been tested through live migrations with virtio-net,
virtio-net-transitional, and virtio-blk devices.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/920b6720bb63893b81516c0c45884a8350f9e4bf; https://git.kernel.org/stable/c/9ef41ebf787fcbde99ac404ae473f8467641f983
CVE: CVE-2025-38315
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btintel: Check dsbr size from EFI variable

Since the size of struct btintel_dsbr is already known, we can just
start there instead of querying the EFI variable size. If the final
result doesn't match what we expect also fail. This fixes a stack buffer
overflow when the EFI variable is larger than struct btintel_dsbr.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-674
References: https://git.kernel.org/stable/c/3aa1dc3c9060e335e82e9c182bf3d1db29220b1b; https://git.kernel.org/stable/c/7b8526bb489780ccc0caffc446ecabec83cfe568; https://git.kernel.org/stable/c/9427f6081f37c795a8bd29d0ee72a4da3bd64af8
CVE: CVE-2025-38316
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: avoid NULL pointer dereference in mt7996_set_monitor()

The function mt7996_set_monitor() dereferences phy before
the NULL sanity check.

Fix this to avoid NULL pointer dereference by moving the
dereference after the check.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/83a422c8169eef95aef57f7ddc467bb126d9ae81; https://git.kernel.org/stable/c/cb423ddad0f6e6f55b1700422ab777b25597cc83
CVE: CVE-2025-38317
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix buffer overflow in debugfs

If the user tries to write more than 32 bytes then it results in memory
corruption.  Fortunately, this is debugfs so it's limited to root users.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0c57aa8ef94cffc5c2d68230e19329a03e71a94f; https://git.kernel.org/stable/c/8c4a200d03574bfcbf54fdb7ba5968b58ad2e0b3; https://git.kernel.org/stable/c/8c7a5031a6b0d42e640fbd2d5d05f61f74e32dce
CVE: CVE-2025-38318
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

perf: arm-ni: Fix missing platform_set_drvdata()

Add missing platform_set_drvdata in arm_ni_probe(), otherwise
calling platform_get_drvdata() in remove returns NULL.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/498129a868ce966af277841f7e32e9f76b3779ad; https://git.kernel.org/stable/c/8e43fa9c713a6d084a5732aa6dd41c734845f25e; https://git.kernel.org/stable/c/fc5106088d6db75df61308ef6de314d1f7959646
CVE: CVE-2025-38319
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table

The function atomctrl_initialize_mc_reg_table() and
atomctrl_initialize_mc_reg_table_v2_2() does not check the return
value of smu_atom_get_data_table(). If smu_atom_get_data_table()
fails to retrieve vram_info, it returns NULL which is later
dereferenced.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/64f3acc8c7e[PII_REDACTED]b75638601b36dea3129; https://git.kernel.org/stable/c/7080c20a[PII_REDACTED]ed4af604dc1fa4028593ad; https://git.kernel.org/stable/c/820116a39f96bdc7d426c33a804b52f53700a919
CVE: CVE-2025-38321
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: Log an error when close_all_cached_dirs fails

Under low-memory conditions, close_all_cached_dirs() can't move the
dentries to a separate list to dput() them once the locks are dropped.
This will result in a "Dentry still in use" error, so add an error
message that makes it clear this is what happened:

[  495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries
[  495.281595] ------------[ cut here ]------------
[  495.281887] BUG: Dentry ffff[PII_REDACTED]38{i=78,n=/}  still in use (2) [unmount of cifs cifs]
[  495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0

Also, bail out of looping through all tcons as soon as a single
allocation fails, since we're already in trouble, and kmalloc() attempts
for subseqeuent tcons are likely to fail just like the first one did.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/43f26094d6702e494e800532c3f1606e7a68eb30; https://git.kernel.org/stable/c/4479db143390bdcadc1561292aab579cdfa9f6c6; https://git.kernel.org/stable/c/a2182743a8b4969481f64aec4908ff162e8a206c
CVE: CVE-2025-38322
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Fix crash in icl_update_topdown_event()

The perf_fuzzer found a hard-lockup crash on a RaptorLake machine:

  Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000
  CPU: 23 UID: 0 PID: 0 Comm: swapper/23
  Tainted: [W]=WARN
  Hardware name: Dell Inc. Precision 9660/0VJ762
  RIP: 0010:native_read_pmc+0x7/0x40
  Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ...
  RSP: 000:fffb03100273de8 EFLAGS: 00010046
  ....
  Call Trace:
    <TASK>
    icl_update_topdown_event+0x165/0x190
    ? ktime_get+0x38/0xd0
    intel_pmu_read_event+0xf9/0x210
    __perf_event_read+0xf9/0x210

CPUs 16-23 are E-core CPUs that don't support the perf metrics feature.
The icl_update_topdown_event() should not be invoked on these CPUs.

It's a regression of commit:

  f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read")

The bug introduced by that commit is that the is_topdown_event() function
is mistakenly used to replace the is_topdown_count() call to check if the
topdown functions for the perf metrics feature should be invoked.

Fix it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/702ea6028032d6c1fe96c2d4762a3575e3654819; https://git.kernel.org/stable/c/79e2dd573116d3338507c311460da9669095c94d; https://git.kernel.org/stable/c/a85cc69acdcb05f8cd226b8ea0778b8e2e887e6f
CVE: CVE-2025-38324
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().

As syzbot reported [0], mpls_route_input_rcu() can be called
from mpls_getroute(), where is under RTNL.

net->mpls.platform_label is only updated under RTNL.

Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to
silence the splat.

[0]:
WARNING: suspicious RCU usage
6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted
 ----------------------------
net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz.2.4451/17730:
 #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
 #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961

stack backtrace:
CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865
 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84
 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381
 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964
 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534
 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
 netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339
 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883
 sock_sendmsg_nosec net/socket.c:712 [inline]
 __sock_sendmsg net/socket.c:727 [inline]
 ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566
 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620
 __sys_sendmmsg+0x200/0x420 net/socket.c:2709
 __do_sys_sendmmsg net/socket.c:2736 [inline]
 __se_sys_sendmmsg net/socket.c:2733 [inline]
 __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0a2818e969
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: 00007f0a28210ab1 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: [PII_REDACTED] R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268
 </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2919297b18e5a5fb7e643f9e32c12c0b17cce1be; https://git.kernel.org/stable/c/36af82f25fbdcd719eb947c15ea874bf80bcf229; https://git.kernel.org/stable/c/49b8a9d7d44401a186e20b1aaf591d2e62727aeb
CVE: CVE-2025-38325
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: add free_transport ops in ksmbd connection

free_transport function for tcp connection can be called from smbdirect.
It will cause kernel oops. This patch add free_transport ops in ksmbd
connection, and add each free_transports for tcp and smbdirect.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3890da762a66191c440b0bd6e3ee45501edbb0c1; https://git.kernel.org/stable/c/3f3aae77280aad9f5acc6709c596148966f765c7; https://git.kernel.org/stable/c/52f5a52dc17a4a7b4363ac03fe2c4ef26f020dc6
CVE: CVE-2025-38326
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

aoe: clean device rq_list in aoedev_downdev()

An aoe device's rq_list contains accepted block requests that are
waiting to be transmitted to the aoe target. This queue was added as
part of the conversion to blk_mq. However, the queue was not cleaned out
when an aoe device is downed which caused blk_mq_freeze_queue() to sleep
indefinitely waiting for those requests to complete, causing a hang. This
fix cleans out the queue before calling blk_mq_freeze_queue().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00be74e1470af292c37a438b8e69dee47dcbf481; https://git.kernel.org/stable/c/531aef4a1accb13b21a3b82ec29955f4733367d5; https://git.kernel.org/stable/c/64fc0bad62ed38874131dd0337d844a43bd1017e
CVE: CVE-2025-38328
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

jffs2: check jffs2_prealloc_raw_node_refs() result in few other places

Fuzzing hit another invalid pointer dereference due to the lack of
checking whether jffs2_prealloc_raw_node_refs() completed successfully.
Subsequent logic implies that the node refs have been allocated.

Handle that. The code is ready for propagating the error upwards.

KASAN: null-ptr-deref in range [0x[PII_REDACTED]000008-0x[PII_REDACTED]00000f]
CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600
Call Trace:
 jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline]
 jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118
 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253
 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167
 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362
 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302
 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347
 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465
 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497
 call_write_iter include/linux/fs.h:2039 [inline]
 do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740
 do_iter_write+0x18c/0x710 fs/read_write.c:866
 vfs_writev+0x1db/0x6a0 fs/read_write.c:939
 do_pwritev fs/read_write.c:1036 [inline]
 __do_sys_pwritev fs/read_write.c:1083 [inline]
 __se_sys_pwritev fs/read_write.c:1078 [inline]
 __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078
 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/042fa922c84b5080401bcd8897d4ac4919d15075; https://git.kernel.org/stable/c/2b6d96503255a3ed676cd70f8368870c6d6a25c6; https://git.kernel.org/stable/c/38d767fb4a7766ec2058f97787e4c6e8d10343d6
CVE: CVE-2025-38329
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: cs_dsp: Fix OOB memory read access in KUnit test (wmfw info)

KASAN reported out of bounds access - cs_dsp_mock_wmfw_add_info(),
because the source string length was rounded up to the allocation size.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0000a2303ba78b6424ff15b5085b5f5098750a2e; https://git.kernel.org/stable/c/d979b783d61f7f1f95664031b71a33afc74627b2
CVE: CVE-2025-38330
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: cs_dsp: Fix OOB memory read access in KUnit test (ctl cache)

KASAN reported out of bounds access - cs_dsp_ctl_cache_init_multiple_offsets().
The code uses mock_coeff_template.length_bytes (4 bytes) for register value
allocations. But later, this length is set to 8 bytes which causes
test code failures.

As fix, just remove the lenght override, keeping the original value 4
for all operations.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/e3dafc64b90546eb769f33333afabd9e3e915757; https://git.kernel.org/stable/c/f4ba2ea57da51d616b689c4b8826c517ff5a8523
CVE: CVE-2025-38331
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: cortina: Use TOE/TSO on all TCP

It is desireable to push the hardware accelerator to also
process non-segmented TCP frames: we pass the skb->len
to the "TOE/TSO" offloader and it will handle them.

Without this quirk the driver becomes unstable and lock
up and and crash.

I do not know exactly why, but it is probably due to the
TOE (TCP offload engine) feature that is coupled with the
segmentation feature - it is not possible to turn one
part off and not the other, either both TOE and TSO are
active, or neither of them.

Not having the TOE part active seems detrimental, as if
that hardware feature is not really supposed to be turned
off.

The datasheet says:

  "Based on packet parsing and TCP connection/NAT table
   lookup results, the NetEngine puts the packets
   belonging to the same TCP connection to the same queue
   for the software to process. The NetEngine puts
   incoming packets to the buffer or series of buffers
   for a jumbo packet. With this hardware acceleration,
   IP/TCP header parsing, checksum validation and
   connection lookup are offloaded from the software
   processing."

After numerous tests with the hardware locking up after
something between minutes and hours depending on load
using iperf3 I have concluded this is necessary to stabilize
the hardware.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1b503b790109d19710ec83c589c3ee59e95347ec; https://git.kernel.org/stable/c/2bd434bb0eeb680c2b3dd6c68ca319b30cb8d47f; https://git.kernel.org/stable/c/6a07e3af4973402fa199a80036c10060b922c92c
CVE: CVE-2025-38332
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Use memcpy() for BIOS version

The strlcat() with FORTIFY support is triggering a panic because it
thinks the target buffer will overflow although the correct target
buffer size is passed in.

Anyway, instead of memset() with 0 followed by a strlcat(), just use
memcpy() and ensure that the resulting buffer is NULL terminated.

BIOSVersion is only used for the lpfc_printf_log() which expects a
properly terminated string.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/003baa7a1a152576d744bd655820449bbdb0248e; https://git.kernel.org/stable/c/2f63bf0d2b146956a2f2ff3b25cee71019e64561; https://git.kernel.org/stable/c/34c0a670556b24d36c9f8934227edb819ca5609e
CVE: CVE-2025-38333
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to bail out in get_new_segment()

------------[ cut here ]------------
WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc
pc : new_curseg+0x5e8/0x6dc
Call trace:
 new_curseg+0x5e8/0x6dc
 f2fs_allocate_data_block+0xa54/0xe28
 do_write_page+0x6c/0x194
 f2fs_do_write_node_page+0x38/0x78
 __write_node_page+0x248/0x6d4
 f2fs_sync_node_pages+0x524/0x72c
 f2fs_write_checkpoint+0x4bc/0x9b0
 __checkpoint_and_complete_reqs+0x80/0x244
 issue_checkpoint_thread+0x8c/0xec
 kthread+0x114/0x1bc
 ret_from_fork+0x10/0x20

get_new_segment() detects inconsistent status in between free_segmap
and free_secmap, let's record such error into super block, and bail
out get_new_segment() instead of continue using the segment.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/bb5eb8a5b222fa5092f60d5555867a05ebc3bdf2; https://git.kernel.org/stable/c/ca860f507a61c7c3d4dde47b830a5c0d555cf83c; https://git.kernel.org/stable/c/f0023d7a2a86999c8e1300e911d92f995a5310a8