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

perf/x86: Fix NULL event access and potential PEBS record loss

When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the
perf_event_overflow() could be called to process the last PEBS record.

While perf_event_overflow() could trigger the interrupt throttle and
stop all events of the group, like what the below call-chain shows.

perf_event_overflow()
  -> __perf_event_overflow()
    ->__perf_event_account_interrupt()
      -> perf_event_throttle_group()
        -> perf_event_throttle()
          -> event->pmu->stop()
            -> x86_pmu_stop()

The side effect of stopping the events is that all corresponding event
pointers in cpuc->events[] array are cleared to NULL.

Assume there are two PEBS events (event a and event b) in a group. When
intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the
last PEBS record of PEBS event a, interrupt throttle is triggered and
all pointers of event a and event b are cleared to NULL. Then
intel_pmu_drain_pebs_icl() tries to process the last PEBS record of
event b and encounters NULL pointer access.

To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop()
to x86_pmu_del(). It's safe since cpuc->active_mask or
cpuc->pebs_enabled is always checked before access the event pointer
from cpuc->events[].
References: https://git.kernel.org/stable/c/6b089028bff1f2ff9e0c62b8f1faca1a620e5d6e; https://git.kernel.org/stable/c/7e772a93eb61cb6265bdd1c5bde17d0f2718b452; https://git.kernel.org/stable/c/cf69b99805c263117305ac6dffbc85aaf9259d32
CVE: CVE-2025-68376
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

coresight: ETR: Fix ETR buffer use-after-free issue

When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed
and enabled again, currently sysfs_buf will point to the newly
allocated memory(buf_new) and free the old memory(buf_old). But the
etr_buf that is being used by the ETR remains pointed to buf_old, not
updated to buf_new. In this case, it will result in a memory
use-after-free issue.

Fix this by checking ETR's mode before updating and releasing buf_old,
if the mode is CS_MODE_SYSFS, then skip updating and releasing it.
References: https://git.kernel.org/stable/c/35501ac3c7d40a7bb9568c2f89d6b56beaf9bed3; https://git.kernel.org/stable/c/70acbc9c77686b7a521af6d7a543dcd9c324cf07; https://git.kernel.org/stable/c/cda077a19f5c8d6ec61e5b97deca203d95e3a422
CVE: CVE-2025-68377
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ns: initialize ns_list_node for initial namespaces

Make sure that the list is always initialized for initial namespaces.
References: https://git.kernel.org/stable/c/3dd50c58664e2684bd610a57bf3ab713cbb0ea91; https://git.kernel.org/stable/c/e31c902d785411eb4a246fba2e8a32aa59d33ce2
CVE: CVE-2025-68378
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix stackmap overflow check in __bpf_get_stackid()

Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()
when copying stack trace data. The issue occurs when the perf trace
 contains more stack entries than the stack map bucket can hold,
 leading to an out-of-bounds write in the bucket's data array.
References: https://git.kernel.org/stable/c/23f852daa4bab4d579110e034e4d513f7d490846; https://git.kernel.org/stable/c/2a008f6de163279deffd488c1deab081bce5667c; https://git.kernel.org/stable/c/4669a8db976c8cbd5427fe9945f12c5fa5168ff3
CVE: CVE-2025-68379
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix null deref on srq->rq.queue after resize failure

A NULL pointer dereference can occur in rxe_srq_chk_attr() when
ibv_modify_srq() is invoked twice in succession under certain error
conditions. The first call may fail in rxe_queue_resize(), which leads
rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then
triggers a crash (null deref) when accessing
srq->rq.queue->buf->index_mask.

Call Trace:
<TASK>
rxe_modify_srq+0x170/0x480 [rdma_rxe]
? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]
? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]
? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]
ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]
? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]
? tryinc_node_nr_active+0xe6/0x150
? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]
? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]
? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]
ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]
? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]
ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]
? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]
? __pfx___raw_spin_lock_irqsave+0x10/0x10
? __pfx_do_vfs_ioctl+0x10/0x10
? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0
? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10
ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]
? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]
__x64_sys_ioctl+0x138/0x1c0
do_syscall_64+0x82/0x250
? fdget_pos+0x58/0x4c0
? ksys_write+0xf3/0x1c0
? __pfx_ksys_write+0x10/0x10
? do_syscall_64+0xc8/0x250
? __pfx_vm_mmap_pgoff+0x10/0x10
? fget+0x173/0x230
? fput+0x2a/0x80
? ksys_mmap_pgoff+0x224/0x4c0
? do_syscall_64+0xc8/0x250
? do_user_addr_fault+0x37b/0xfe0
? clear_bhb_loop+0x50/0xa0
? clear_bhb_loop+0x50/0xa0
? clear_bhb_loop+0x50/0xa0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
References: https://git.kernel.org/stable/c/503a5e4690ae14c18570141bc0dcf7501a8419b0; https://git.kernel.org/stable/c/58aca869babd48cb9c3d6ee9e1452c4b9f5266a6; https://git.kernel.org/stable/c/5dbeb421e137824aa9bd8358bdfc926a3965fc0d
CVE: CVE-2025-68380
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix peer HE MCS assignment

In ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent to
firmware as receive MCS while peer's receive MCS sent as transmit MCS,
which goes against firmwire's definition.

While connecting to a misbehaved AP that advertises 0xffff (meaning not
supported) for 160 MHz transmit MCS map, firmware crashes due to 0xffff
is assigned to he_mcs->rx_mcs_set field.

	Ext Tag: HE Capabilities
	    [...]
	    Supported HE-MCS and NSS Set
		[...]
	        Rx and Tx MCS Maps 160 MHz
		    [...]
	            Tx HE-MCS Map 160 MHz: 0xffff

Swap the assignment to fix this issue.

As the HE rate control mask is meant to limit our own transmit MCS, it
needs to go via he_mcs->rx_mcs_set field. With the aforementioned swapping
done, change is needed as well to apply it to the peer's receive MCS.

Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
References: https://git.kernel.org/stable/c/097c870b91817779e5a312c6539099a884b1fe2b; https://git.kernel.org/stable/c/381096a417b7019896e93e86f4c585c592bf98e2; https://git.kernel.org/stable/c/4304bd7a334e981f189b9973056a58f84cc2b482
CVE: CVE-2025-68724
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id

Use check_add_overflow() to guard against potential integer overflows
when adding the binary blob lengths and the size of an asymmetric_key_id
structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a
possible buffer overflow when copying data from potentially malicious
X.509 certificate fields that can be arbitrarily large, such as ASN.1
INTEGER serial numbers, issuer names, etc.
References: https://git.kernel.org/stable/c/5b8ac617c8dab5cad3c4dc8d84d0987808a0f99c; https://git.kernel.org/stable/c/60a7be5ee74408147e439164ac067e418ca74bb4; https://git.kernel.org/stable/c/6af753ac5205115e6c310c8c4236c01b59a1c44f
CVE: CVE-2025-68725
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Do not let BPF test infra emit invalid GSO types to stack

Yinhao et al. reported that their fuzzer tool was able to trigger a
skb_warn_bad_offload() from netif_skb_features() -> gso_features_check().
When a BPF program - triggered via BPF test infra - pushes the packet
to the loopback device via bpf_clone_redirect() then mentioned offload
warning can be seen. GSO-related features are then rightfully disabled.

We get into this situation due to convert___skb_to_skb() setting
gso_segs and gso_size but not gso_type. Technically, it makes sense
that this warning triggers since the GSO properties are malformed due
to the gso_type. Potentially, the gso_type could be marked non-trustworthy
through setting it at least to SKB_GSO_DODGY without any other specific
assumptions, but that also feels wrong given we should not go further
into the GSO engine in the first place.

The checks were added in 121d57af308d ("gso: validate gso_type in GSO
handlers") because there were malicious (syzbot) senders that combine
a protocol with a non-matching gso_type. If we would want to drop such
packets, gso_features_check() currently only returns feature flags via
netif_skb_features(), so one location for potentially dropping such skbs
could be validate_xmit_unreadable_skb(), but then otoh it would be
an additional check in the fast-path for a very corner case. Given
bpf_clone_redirect() is the only place where BPF test infra could emit
such packets, lets reject them right there.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04a899573fb87273a656f178b5f920c505f68875; https://git.kernel.org/stable/c/0f3a60869ca22024dfb9c6fce412b0c70cb4ea36; https://git.kernel.org/stable/c/768376ece7036ecb[PII_REDACTED]a1b72afe6345dd
CVE: CVE-2025-68726
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: aead - Fix reqsize handling

Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")
introduced cra_reqsize field in crypto_alg struct to replace type
specific reqsize fields. It looks like this was introduced specifically
for ahash and acomp from the commit description as subsequent commits
add necessary changes in these alg frameworks.

However, this is being recommended for use in all crypto algs
instead of setting reqsize using crypto_*_set_reqsize(). Using
cra_reqsize in aead algorithms, hence, causes memory corruptions and
crashes as the underlying functions in the algorithm framework have not
been updated to set the reqsize properly from cra_reqsize. [1]

Add proper set_reqsize calls in the aead init function to properly
initialize reqsize for these algorithms in the framework.

[1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b
References: https://git.kernel.org/stable/c/12b413f5460c393d1151a37f591140693eca0f84; https://git.kernel.org/stable/c/64377e66e187164bd6737112d07257f5f0feb681; https://git.kernel.org/stable/c/9b04d8f[PII_REDACTED]6dd05397f[PII_REDACTED]eb24
CVE: CVE-2025-68727
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ntfs3: Fix uninit buffer allocated by __getname()

Fix uninit errors caused after buffer allocation given to 'de'; by
initializing the buffer with zeroes. The fix was found by using KMSAN.
References: https://git.kernel.org/stable/c/4b1fd82848fdf0e01b3320815b261006c1722c3e; https://git.kernel.org/stable/c/53f4d6cb[PII_REDACTED]0f3719f75cdf9fc5120f37; https://git.kernel.org/stable/c/90e23db1a[PII_REDACTED]9c18e76f402542cb004da
CVE: CVE-2025-68728
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ntfs3: fix uninit memory after failed mi_read in mi_format_new

Fix a KMSAN un-init bug found by syzkaller.

ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be
uptodate. We do not bring the buffer uptodate before setting it as
uptodate. If the buffer were to not be uptodate, it could mean adding a
buffer with un-init data to the mi record. Attempting to load that record
will trigger KMSAN.

Avoid this by setting the buffer as uptodate, if it’s not already, by
overwriting it.
References: https://git.kernel.org/stable/c/46f2a881e5a7311d41551edb3915e4d4e8802341; https://git.kernel.org/stable/c/73e6b9dacf72a1e7a4265eacca46f8f33e0997d6; https://git.kernel.org/stable/c/7ce8f2028dfccb2161b905cf8ab85cdd9e93909c
CVE: CVE-2025-68729
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix MSDU buffer types handling in RX error path

Currently, packets received on the REO exception ring from
unassociated peers are of MSDU buffer type, while the driver expects
link descriptor type packets. These packets are not parsed further due
to a return check on packet type in ath12k_hal_desc_reo_parse_err(),
but the associated skb is not freed. This may lead to kernel
crashes and buffer leaks.

Hence to fix, update the RX error handler to explicitly drop
MSDU buffer type packets received on the REO exception ring.
This prevents further processing of invalid packets and ensures
stability in the RX error handling path.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
References: https://git.kernel.org/stable/c/36f9edbb9d0fc36c865c74f3c1ad8e1261ad3981; https://git.kernel.org/stable/c/5ff5a9d71cdc49c3400f30583a784ad0a17d01ec; https://git.kernel.org/stable/c/ab0554f51e5f2b9506e8a09e8accd02f00056729
CVE: CVE-2025-68730
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix page fault in ivpu_bo_unbind_all_bos_from_context()

Don't add BO to the vdev->bo_list in ivpu_gem_create_object().
When failure happens inside drm_gem_shmem_create(), the BO is not
fully created and ivpu_gem_bo_free() callback will not be called
causing a deleted BO to be left on the list.
References: https://git.kernel.org/stable/c/8172838a284c27190fa6782c2740a[PII_REDACTED]0; https://git.kernel.org/stable/c/8b694b405a84696f1d964f6da7cf9721e68c4714; https://git.kernel.org/stable/c/c9ef5ccd8bd9bcf598b6d3f77e7eb4dde7149aec
CVE: CVE-2025-68731
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/amdxdna: Fix an integer overflow in aie2_query_ctx_status_array()

The unpublished smatch static checker reported a warning.

drivers/accel/amdxdna/aie2_pci.c:904 aie2_query_ctx_status_array()
warn: potential user controlled sizeof overflow
'args->num_element * args->element_size' '1-u32max(user) * 1-u32max(user)'

Even this will not cause a real issue, it is better to put a reasonable
limitation for element_size and num_element. Add condition to make sure
the input element_size <= 4K and num_element <= 1K.
References: https://git.kernel.org/stable/c/359653edd5374fbba28f93043554dcc494aee85f; https://git.kernel.org/stable/c/9e16c8bf9aebf629344cfd4cd5e3dc7d8c3f7d82
CVE: CVE-2025-68732
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

gpu: host1x: Fix race in syncpt alloc/free

Fix race condition between host1x_syncpt_alloc()
and host1x_syncpt_put() by using kref_put_mutex()
instead of kref_put() + manual mutex locking.

This ensures no thread can acquire the
syncpt_mutex after the refcount drops to zero
but before syncpt_release acquires it.
This prevents races where syncpoints could
be allocated while still being cleaned up
from a previous release.

Remove explicit mutex locking in syncpt_release
as kref_put_mutex() handles this atomically.
References: https://git.kernel.org/stable/c/4aeaece518fa4436af93d1d8b786200d9656ff4b; https://git.kernel.org/stable/c/4e6e07ce0197aecfb6c4a62862acc93b3efedeb7; https://git.kernel.org/stable/c/6245cce711e2cdb2cc75c0bb8632952e36f8c972
CVE: CVE-2025-68733
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

smack: fix bug: unprivileged task can create labels

If an unprivileged task is allowed to relabel itself
(/smack/relabel-self is not empty),
it can freely create new labels by writing their
names into own /proc/PID/attr/smack/current

This occurs because do_setattr() imports
the provided label in advance,
before checking "relabel-self" list.

This change ensures that the "relabel-self" list
is checked before importing the label.
References: https://git.kernel.org/stable/c/4a7a7621619a366712fb9cefcb6e69f956c247ce; https://git.kernel.org/stable/c/60e8d49989410a7ade60f5dadfcd979c117d05c0; https://git.kernel.org/stable/c/64aa81250171b6bb6803e97ea7a5d73bfa061f6e
CVE: CVE-2025-68734
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()

In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when
setup_instance() fails with an error code. Fix that by freeing the urb
before freeing the hw structure. Also change the error paths to use the
goto ladder style.

Compile tested only. Issue found using a prototype static analysis tool.
References: https://git.kernel.org/stable/c/03695541b3349bc40bf5d6563d44d6147fb20260; https://git.kernel.org/stable/c/3f7c72bc73c4e542fde14cce017549d8a0b61a3c; https://git.kernel.org/stable/c/3f978e3f1570155a1327ffa25f60968bc7b9398f
CVE: CVE-2022-50712
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

devlink: hold region lock when flushing snapshots

Netdevsim triggers a splat on reload, when it destroys regions
with snapshots pending:

  WARNING: CPU: 1 PID: 787 at net/core/devlink.c:6291 devlink_region_snapshot_del+0x12e/0x140
  CPU: 1 PID: 787 Comm: devlink Not tainted 6.1.0-07460-g7ae9888d6e1c #580
  RIP: 0010:devlink_region_snapshot_del+0x12e/0x140
  Call Trace:
   <TASK>
   devl_region_destroy+0x70/0x140
   nsim_dev_reload_down+0x2f/0x60 [netdevsim]
   devlink_reload+0x1f7/0x360
   devlink_nl_cmd_reload+0x6ce/0x860
   genl_family_rcv_msg_doit.isra.0+0x145/0x1c0

This is the locking assert in devlink_region_snapshot_del(),
we're supposed to be holding the region->snapshot_lock here.
References: https://git.kernel.org/stable/c/49383d4e59bb704341aaa1d51440ccce58270e61; https://git.kernel.org/stable/c/6298cab4d80bfdb6fe01fe31fd9f0ba26317fdae; https://git.kernel.org/stable/c/b4cafb3d2c740f8d1b1234b43ac4a60e5291c960
CVE: CVE-2022-50713
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: visconti: Fix memory leak in visconti_register_pll()

@pll->rate_table has allocated memory by kmemdup(), if clk_hw_register()
fails, it should be freed, otherwise it will cause memory leak issue,
this patch fixes it.
References: https://git.kernel.org/stable/c/70af9bf13be1716eac452c8a29ce6fe6b957a5db; https://git.kernel.org/stable/c/b55226f8553d255f5002c751c7c6ba9291f34bf2; https://git.kernel.org/stable/c/f0f1982ddfb418bf7bf05dadebae5c6869a41d41
CVE: CVE-2022-50714
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7921e: fix rmmod crash in driver reload test

In insmod/rmmod stress test, the following crash dump shows up immediately.
The problem is caused by missing mt76_dev in mt7921_pci_remove(). We
should make sure the drvdata is ready before probe() finished.

[168.862789] ==================================================================
[168.862797] BUG: KASAN: user-memory-access in try_to_grab_pending+0x59/0x480
[168.862805] Write of size 8 at addr[PII_REDACTED]006df0 by task rmmod/5361
[168.862812] CPU: 7 PID: 5361 Comm: rmmod Tainted: G           OE     5.19.0-rc6 #1
[168.862816] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, 05/04/2020
[168.862820] Call Trace:
[168.862822]  <TASK>
[168.862825]  dump_stack_lvl+0x49/0x63
[168.862832]  print_report.cold+0x493/0x6b7
[168.862845]  kasan_report+0xa7/0x120
[168.862857]  kasan_check_range+0x163/0x200
[168.862861]  __kasan_check_write+0x14/0x20
[168.862866]  try_to_grab_pending+0x59/0x480
[168.862870]  __cancel_work_timer+0xbb/0x340
[168.862898]  cancel_work_sync+0x10/0x20
[168.862902]  mt7921_pci_remove+0x61/0x1c0 [mt7921e]
[168.862909]  pci_device_remove+0xa3/0x1d0
[168.862914]  device_remove+0xc4/0x170
[168.862920]  device_release_driver_internal+0x163/0x300
[168.862925]  driver_detach+0xc7/0x1a0
[168.862930]  bus_remove_driver+0xeb/0x2d0
[168.862935]  driver_unregister+0x71/0xb0
[168.862939]  pci_unregister_driver+0x30/0x230
[168.862944]  mt7921_pci_driver_exit+0x10/0x1b [mt7921e]
[168.862949]  __x64_sys_delete_module+0x2f9/0x4b0
[168.862968]  do_syscall_64+0x38/0x90
[168.862973]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

Test steps:
1. insmode
2. do not ifup
3. rmmod quickly (within 1 second)
References: https://git.kernel.org/stable/c/1034d8e[PII_REDACTED]1377f136a060e78fc24f2a5; https://git.kernel.org/stable/c/b5a62d612b7baf6e09884e4de94decb6391d6a9d; https://git.kernel.org/stable/c/ccda3ebdae719d348f90563b6719fba4929ae283
CVE: CVE-2022-50715
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid1: stop mdx_raid1 thread when raid1 array run failed

fail run raid1 array when we assemble array with the inactive disk only,
but the mdx_raid1 thread were not stop, Even if the associated resources
have been released. it will caused a NULL dereference when we do poweroff.

This causes the following Oops:
    [  287.587787] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    [  287.594762] #PF: supervisor read access in kernel mode
    [  287.599912] #PF: error_code(0x0000) - not-present page
    [  287.605061] PGD 0 P4D 0
    [  287.607612] Oops: 0000 [#1] SMP NOPTI
    [  287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G     U            5.10.146 #0
    [  287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022
    [  287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod]
    [  287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ......
    [  287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202
    [  287.656347] RAX: [PII_REDACTED] RBX: ffff[PII_REDACTED]00 RCX: [PII_REDACTED]
    [  287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff[PII_REDACTED]00
    [  287.670634] RBP: ffffc90000433da0 R08: [PII_REDACTED] R09: c0000000ffffefff
    [  287.677771] R10: [PII_REDACTED] R11: ffffc90000433ba8 R12: ffff[PII_REDACTED]00
    [  287.684907] R13: [PII_REDACTED] R14: fffffffffffffe00 R15: ffff888100b6b500
    [  287.692052] FS:  [PII_REDACTED](0000) GS:ffff888277f80000(0000) knlGS:[PII_REDACTED]
    [  287.700149] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
    [  287.705897] CR2: [PII_REDACTED] CR3:[PII_REDACTED]20a000 CR4:[PII_REDACTED]350ee0
    [  287.713033] Call Trace:
    [  287.715498]  raid1d+0x6c/0xbbb [raid1]
    [  287.719256]  ? __schedule+0x1ff/0x760
    [  287.722930]  ? schedule+0x3b/0xb0
    [  287.726260]  ? schedule_timeout+0x1ed/0x290
    [  287.730456]  ? __switch_to+0x11f/0x400
    [  287.734219]  md_thread+0xe9/0x140 [md_mod]
    [  287.738328]  ? md_thread+0xe9/0x140 [md_mod]
    [  287.742601]  ? wait_woken+0x80/0x80
    [  287.746097]  ? md_register_thread+0xe0/0xe0 [md_mod]
    [  287.751064]  kthread+0x11a/0x140
    [  287.754300]  ? kthread_park+0x90/0x90
    [  287.757974]  ret_from_fork+0x1f/0x30

In fact, when raid1 array run fail, we need to do
md_unregister_thread() before raid1_free().
References: https://git.kernel.org/stable/c/0c7c7468c3ae222e297b7dc74d6ccb69c4d0183c; https://git.kernel.org/stable/c/10d713532ffc67b13df61ed9c138a8ce0a186236; https://git.kernel.org/stable/c/110f14a7b2eb5b8aa9df5af2d629524f2a07d543
CVE: CVE-2022-50717
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

nvmet-tcp: add bounds check on Transfer Tag

ttag is used as an index to get cmd in nvmet_tcp_handle_h2c_data_pdu(),
add a bounds check to avoid out-of-bounds access.
References: https://git.kernel.org/stable/c/0d150ccd55dbfad36f55855b40b381884c98456e; https://git.kernel.org/stable/c/752593d04637ebdc87fd29cba81897f21ae053f0; https://git.kernel.org/stable/c/b6a545ffa2c192b1e6da4a7924edac5ba9f4ea2b