deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50038
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors()

In this function, there are two refcount leak bugs:
(1) when breaking out of for_each_endpoint_of_node(), we need call
the of_node_put() for the 'ep';
(2) we should call of_node_put() for the reference returned by
of_graph_get_remote_port() when it is not used anymore.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3aa710e96747c8b4e52ba12ffe09edcb2755897c; https://git.kernel.org/stable/c/6a758f0ba11699837af9e1a0f7cbac6ef765a23e; https://git.kernel.org/stable/c/8dec38e19f6928235d4009ce55f7add8af34e5c7
CVE: CVE-2022-50039
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove()

Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove
paths") removed this clk_disable_unprepare()

This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock
handling on remove path") which removed this clk_disable_unprepare()
because:
"
   While unloading the dwmac-intel driver, clk_disable_unprepare() is
   being called twice in stmmac_dvr_remove() and
   intel_eth_pci_remove(). This causes kernel panic on the second call.
"

However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management
for gmac driver") has updated stmmac_dvr_remove() which do not call
clk_disable_unprepare() anymore.

So this call should now be called from intel_eth_pci_remove().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02f3642d8e657c05f382729c165bed46745dc18c; https://git.kernel.org/stable/c/[PII_REDACTED]6054b[PII_REDACTED]65b47a43cdb6f41; https://git.kernel.org/stable/c/5c23d6b717e4e956376f3852b90f58e262946b50
CVE: CVE-2022-50040
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions()

If an error occurs in dsa_devlink_region_create(), then 'priv->regions'
array will be accessed by negative index '-1'.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/7983e1e44cb322eba6af84160b6d18df80603fb8; https://git.kernel.org/stable/c/79f86b862416126a2e826cb74224180d6625a32f; https://git.kernel.org/stable/c/e84c6321f3578c38cb3c24258db91a92672b17a8
CVE: CVE-2022-50042
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: genl: fix error path memory leak in policy dumping

If construction of the array of policies fails when recording
non-first policy we need to unwind.

netlink_policy_dump_add_policy() itself also needs fixing as
it currently gives up on error without recording the allocated
pointer in the pstate pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/249801360db3dec4f73768c502192020bfddeacc; https://git.kernel.org/stable/c/26b6acd365823e99e46be3b27500f5dc235dda5e; https://git.kernel.org/stable/c/83411c9f05d5a8b637293b3389eca3d378197c04
CVE: CVE-2022-50043
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: fix potential refcount leak in ndisc_router_discovery()

The issue happens on specific paths in the function. After both the
object `rt` and `neigh` are grabbed successfully, when `lifetime` is
nonzero but the metric needs change, the function just deletes the
route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`
again if above conditions hold. The function simply overwrite `neigh`
if succeeds or returns if fails, without decreasing the reference
count of previous `neigh`. This may result in memory leaks.

Fix it by decrementing the reference count of `neigh` in place.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7396ba87f1edf[PII_REDACTED]51665c7c4e74ecd4f; https://git.kernel.org/stable/c/7998043d31d000c3a93f46182e6569dd0eecda34; https://git.kernel.org/stable/c/ffb[PII_REDACTED]fd7885eb88ce5a7f7bdeefbb15
CVE: CVE-2022-50044
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: qrtr: start MHI channel after endpoit creation

MHI channel may generates event/interrupt right after enabling.
It may leads to 2 race conditions issues.

1)
Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check:

	if (!qdev || mhi_res->transaction_status)
		return;

Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at
this moment. In this situation qrtr-ns will be unable to enumerate
services in device.
---------------------------------------------------------------

2)
Such event may come at the moment after dev_set_drvdata() and
before qrtr_endpoint_register(). In this case kernel will panic with
accessing wrong pointer at qcom_mhi_qrtr_dl_callback():

	rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr,
				mhi_res->bytes_xferd);

Because endpoint is not created yet.
--------------------------------------------------------------
So move mhi_prepare_for_transfer_autoqueue after endpoint creation
to fix it.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/68a838b84effb7b57ba7d50b1863fc6ae35a54ce; https://git.kernel.org/stable/c/a1a75f78a[PII_REDACTED]b1b756f82462874b5ca20; https://git.kernel.org/stable/c/c682fb70a7dfc25b848a4ff3a385b0471b470606
CVE: CVE-2022-50045
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/pci: Fix get_phb_number() locking

The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP
warning on some systems:

  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper
  preempt_count: 1, expected: 0
  RCU nest depth: 0, expected: 0
  1 lock held by swapper/1:
   #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220
  Preemption disabled at:
  [<00000000>] 0x0
  CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1
  Call Trace:
  [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable)
  [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8
  [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec
  [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4
  [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220
  [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784
  [d101de50] [c140852c] discover_phbs+0x30/0x4c
  [d101de60] [c0007fd4] do_one_initcall+0x94/0x344
  [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c
  [d101df10] [c00086e0] kernel_init+0x34/0x160
  [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64

This is because pcibios_alloc_controller() holds hose_spinlock but
of_alias_get_id() takes of_mutex which can sleep.

The hose_spinlock protects the phb_bitmap, and also the hose_list, but
it doesn't need to be held while get_phb_number() calls the OF routines,
because those are only looking up information in the device tree.

So fix it by having get_phb_number() take the hose_spinlock itself, only
where required, and then dropping the lock before returning.
pcibios_alloc_controller() then needs to take the lock again before the
list_add() but that's safe, the order of the list is not important.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/1d9e75c3d8cdf7c96a94cb77450d4ee070279e6a; https://git.kernel.org/stable/c/5db5ce0f1963c6c8275719a80cb65e9c98d32726; https://git.kernel.org/stable/c/6f75057c21eab12c6ccb7f06f859641a6edfab99
CVE: CVE-2022-50046
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()

The issue happens on some error handling paths. When the function
fails to grab the object `xprt`, it simply returns 0, forgetting to
decrease the reference count of another object `xps`, which is
increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount
leaks. Also, the function forgets to check whether `xps` is valid
before using it, which may result in NULL-dereferencing issues.

Fix it by adding proper error handling code when either `xprt` or
`xps` is NULL.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/76fbeb1662b1c[PII_REDACTED]8a07fba74dc4c79fe; https://git.kernel.org/stable/c/bfc48f1b0505ffcb03a6d749139b7577d6b81ae0; https://git.kernel.org/stable/c/c0434f0e[PII_REDACTED]50b8ed6078b66d773de723
CVE: CVE-2022-50047
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: mv88e6060: prevent crash on an unused port

If the port isn't a CPU port nor a user port, 'cpu_dp'
is a null pointer and a crash happened on dereferencing
it in mv88e6060_setup_port():

[    9.575872] Unable to handle kernel NULL pointer dereference at virtual address 00000014
...
[    9.942216]  mv88e6060_setup from dsa_register_switch+0x814/0xe84
[    9.948616]  dsa_register_switch from mdio_probe+0x2c/0x54
[    9.954433]  mdio_probe from really_probe.part.0+0x98/0x2a0
[    9.960375]  really_probe.part.0 from driver_probe_device+0x30/0x10c
[    9.967029]  driver_probe_device from __device_attach_driver+0xb8/0x13c
[    9.973946]  __device_attach_driver from bus_for_each_drv+0x90/0xe0
[    9.980509]  bus_for_each_drv from __device_attach+0x110/0x184
[    9.986632]  __device_attach from bus_probe_device+0x8c/0x94
[    9.992577]  bus_probe_device from deferred_probe_work_func+0x78/0xa8
[    9.999311]  deferred_probe_work_func from process_one_work+0x290/0x73c
[   10.006292]  process_one_work from worker_thread+0x30/0x4b8
[   10.012155]  worker_thread from kthread+0xd4/0x10c
[   10.017238]  kthread from ret_from_fork+0x14/0x3c
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/246bbf2f977ea36aaf41f5d24370fef433250728; https://git.kernel.org/stable/c/92dc64e8f591425ce4dabf7d479ebf6e67fb8853; https://git.kernel.org/stable/c/cb1753bc689c7a7f94da6eee7efc1ae6d8abb36c
CVE: CVE-2022-50048
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: possible module reference underflow in error path

dst->ops is set on when nft_expr_clone() fails, but module refcount has
not been bumped yet, therefore nft_expr_destroy() leads to module
reference underflow.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1e52e6cfec6342c3d0df47dc3a76724fb3dabf56; https://git.kernel.org/stable/c/b59bee8b05b0e789b5a298cacb09e8aaa3367a29; https://git.kernel.org/stable/c/c485c35ff6783ccd12c160fcac6a0e504e83e0bf
CVE: CVE-2022-50049
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: DPCM: Don't pick up BE without substream

When DPCM tries to add valid BE connections at dpcm_add_paths(), it
doesn't check whether the picked BE actually supports for the given
stream direction.  Due to that, when an asymmetric BE stream is
present, it picks up wrongly and this may result in a NULL dereference
at a later point where the code assumes the existence of a
corresponding BE substream.

This patch adds the check for the presence of the substream for the
target BE for avoiding the problem above.

Note that we have already some fix for non-existing BE substream at
commit 6246f283d5e0 ("ASoC: dpcm: skip missing substream while
applying symmetry").  But the code path we've hit recently is rather
happening before the previous fix.  So this patch tries to fix at
picking up a BE instead of parsing BE lists.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6a840e8ef6b6c56d1b7e6a555adc31135e517875; https://git.kernel.org/stable/c/754590651ccbbcc74a7c20907be4bb15d642bde3; https://git.kernel.org/stable/c/aa803e6ecac78e93b24ebefa17c207d6392d8ad4
CVE: CVE-2022-50050
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()

snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).

This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/6ee1310f4d148dbf04c4159b88afd0b941018903; https://git.kernel.org/stable/c/94c1ceb043c1a002de9649bb630c8e[PII_REDACTED]; https://git.kernel.org/stable/c/f7915c5614a7ece117ec390f21a410531eac48de
CVE: CVE-2022-50051
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: debug: Fix potential buffer overflow by snprintf()

snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).

This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1eb123ce985e6cf302ac6e3f19862d132d86fa8f; https://git.kernel.org/stable/c/a67971a17604ae7de278fb[PII_REDACTED]9afc51e1; https://git.kernel.org/stable/c/b318b9dd2ac67f39d0338ce563879d1f59a0347a
CVE: CVE-2022-50052
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: avs: Fix potential buffer overflow by snprintf()

snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in a buffer
overflow (although it's unrealistic).

This patch replaces it with a safer version, scnprintf() for papering
over such a potential issue.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/840311a09f75632b9d41fbc1cd5c7aea94ce5f7e; https://git.kernel.org/stable/c/ca3b7b9dc9bc1fa552f4697b7cccfa0258a44d00
CVE: CVE-2022-50055
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix adminq error handling

iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent
memory for VF mailbox.
Free DMA regions for both ASQ and ARQ in case error happens during
configuration of ASQ/ARQ registers.
Without this change it is possible to see when unloading interface:
74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32]
One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/35c63581fdefdcbaeae8cded[PII_REDACTED]353ad; https://git.kernel.org/stable/c/419831617ed349992c84344dbd9e627f9e68f842; https://git.kernel.org/stable/c/4fe80492d53971d9a49f39f3c86d2d67c6f3638a
CVE: CVE-2022-50056
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix missing i_op in ntfs_read_mft

There is null pointer dereference because i_op == NULL.
The bug happens because we don't initialize i_op for records in $Extend.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/37a530bfe56ca9a0d[PII_REDACTED]f2794c7428aae; https://git.kernel.org/stable/c/8089a1bc27b41e6800590a92d17c119e9aa8ff53; https://git.kernel.org/stable/c/c293e8abc09e6e1faa50d967bd8862b1cbd575e5
CVE: CVE-2022-50057
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix NULL deref in ntfs_update_mftmirr

If ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL.
Code should check this ptr before dereferencing. Syzbot hit this issue
via passing wrong mount param as can be seen from log below

Fail log:
ntfs3: Unknown parameter 'iochvrset'
general protection fault, probably for non-canonical address 0xdffffc[PII_REDACTED]: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000018-0x[PII_REDACTED]00001f]
CPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0
...
Call Trace:
 <TASK>
 put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463
 ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363
 put_fs_context+0x119/0x7a0 fs/fs_context.c:469
 do_new_mount+0x2b4/0xad0 fs/namespace.c:3044
 do_mount fs/namespace.c:3383 [inline]
 __do_sys_mount fs/namespace.c:3591 [inline]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/321460ca3b55f48b3ba[PII_REDACTED]ab2bd6407d9; https://git.kernel.org/stable/c/8e8e1a84dac7a3d2b432162a70d7fb6a75960772; https://git.kernel.org/stable/c/bf6089dc01ba3194ab962105d7b85690843c256f
CVE: CVE-2022-50058
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

vdpa_sim_blk: set number of address spaces and virtqueue groups

Commit bda324fd037a ("vdpasim: control virtqueue support") added two
new fields (nas, ngroups) to vdpasim_dev_attr, but we forgot to
initialize them for vdpa_sim_blk.

When creating a new vdpa_sim_blk device this causes the kernel
to panic in this way:
    $ vdpa dev add mgmtdev vdpasim_blk name blk0
    BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
    ...
    RIP: 0010:vhost_iotlb_add_range_ctx+0x41/0x220 [vhost_iotlb]
    ...
    Call Trace:
     <TASK>
     vhost_iotlb_add_range+0x11/0x800 [vhost_iotlb]
     vdpasim_map_range+0x91/0xd0 [vdpa_sim]
     vdpasim_alloc_coherent+0x56/0x90 [vdpa_sim]
     ...

This happens because vdpasim->iommu[0] is not initialized when
dev_attr.nas is 0.

Let's fix this issue by initializing both (nas, ngroups) to 1 for
vdpa_sim_blk.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/19cd4a5471b8eaa4bd161b0fdb4567f2fc88d809; https://git.kernel.org/stable/c/a291c7d289fac2cb13fb2614a9a251afbbd86ce9
CVE: CVE-2022-50059
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: don't leak snap_rwsem in handle_cap_grant

When handle_cap_grant is called on an IMPORT op, then the snap_rwsem is
held and the function is expected to release it before returning. It
currently fails to do that in all cases which could lead to a deadlock.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/58dd4385577ed7969b80cdc9e2a31575aba6c712; https://git.kernel.org/stable/c/a090cc69699ec2d11b5e34cee8c61f0d4b0068cb; https://git.kernel.org/stable/c/aee18421bda6bf12a7cba6a3d7751c0e1cfd0094
CVE: CVE-2022-50060
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Fix mcam entry resource leak

The teardown sequence in FLR handler returns if no NIX LF
is attached to PF/VF because it indicates that graceful
shutdown of resources already happened. But there is a
chance of all allocated MCAM entries not being freed by
PF/VF. Hence free mcam entries even in case of detached LF.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3f8fe40ab7730cf8eb6f8b8ff412012f7f6f8f48; https://git.kernel.org/stable/c/cc32347f48111eea8d0165538c92aca92ede83f6; https://git.kernel.org/stable/c/dc5be2d4f9285efe0d16f1bf00250df91d05d809
CVE: CVE-2022-50061
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: nomadik: Fix refcount leak in nmk_pinctrl_dt_subnode_to_map

of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak."
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4b32e054335ea0ce50967f63a7bfd4db058b14b9; https://git.kernel.org/stable/c/587ac8ac00a1a9f[PII_REDACTED]d9441870fd7b187; https://git.kernel.org/stable/c/78d05103891d3e96144b846fbc39f2cfb3384eae
CVE: CVE-2022-50063
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: felix: suppress non-changes to the tagging protocol

The way in which dsa_tree_change_tag_proto() works is that when
dsa_tree_notify() fails, it doesn't know whether the operation failed
mid way in a multi-switch tree, or it failed for a single-switch tree.
So even though drivers need to fail cleanly in
ds->ops->change_tag_protocol(), DSA will still call dsa_tree_notify()
again, to restore the old tag protocol for potential switches in the
tree where the change did succeeed (before failing for others).

This means for the felix driver that if we report an error in
felix_change_tag_protocol(), we'll get another call where proto_ops ==
old_proto_ops. If we proceed to act upon that, we may do unexpected
things. For example, we will call dsa_tag_8021q_register() twice in a
row, without any dsa_tag_8021q_unregister() in between. Then we will
actually call dsa_tag_8021q_unregister() via old_proto_ops->teardown,
which (if it manages to run at all, after walking through corrupted data
structures) will leave the ports inoperational anyway.

The bug can be readily reproduced if we force an error while in
tag_8021q mode; this crashes the kernel.

echo ocelot-8021q > /sys/class/net/eno2/dsa/tagging
echo edsa > /sys/class/net/eno2/dsa/tagging # -EPROTONOSUPPORT

Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
Call trace:
 vcap_entry_get+0x24/0x124
 ocelot_vcap_filter_del+0x198/0x270
 felix_tag_8021q_vlan_del+0xd4/0x21c
 dsa_switch_tag_8021q_vlan_del+0x168/0x2cc
 dsa_switch_event+0x68/0x1170
 dsa_tree_notify+0x14/0x34
 dsa_port_tag_8021q_vlan_del+0x84/0x110
 dsa_tag_8021q_unregister+0x15c/0x1c0
 felix_tag_8021q_teardown+0x16c/0x180
 felix_change_tag_protocol+0x1bc/0x230
 dsa_switch_event+0x14c/0x1170
 dsa_tree_change_tag_proto+0x118/0x1c0
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4c46bb49460ee14c69629e813640d8b929e88941; https://git.kernel.org/stable/c/8e432f157c3edc5a97a7244c666589a438f5e4d4
CVE: CVE-2022-50064
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-blk: Avoid use-after-free on suspend/resume

hctx->user_data is set to vq in virtblk_init_hctx().  However, vq is
freed on suspend and reallocated on resume.  So, hctx->user_data is
invalid after resume, and it will cause use-after-free accessing which
will result in the kernel crash something like below:

[   22.428391] Call Trace:
[   22.428899]  <TASK>
[   22.429339]  virtqueue_add_split+0x3eb/0x620
[   22.430035]  ? __blk_mq_alloc_requests+0x17f/0x2d0
[   22.430789]  ? kvm_clock_get_cycles+0x14/0x30
[   22.431496]  virtqueue_add_sgs+0xad/0xd0
[   22.432108]  virtblk_add_req+0xe8/0x150
[   22.432692]  virtio_queue_rqs+0xeb/0x210
[   22.433330]  blk_mq_flush_plug_list+0x1b8/0x280
[   22.434059]  __blk_flush_plug+0xe1/0x140
[   22.434853]  blk_finish_plug+0x20/0x40
[   22.435512]  read_pages+0x20a/0x2e0
[   22.436063]  ? folio_add_lru+0x62/0xa0
[   22.436652]  page_cache_ra_unbounded+0x112/0x160
[   22.437365]  filemap_get_pages+0xe1/0x5b0
[   22.437964]  ? context_to_sid+0x70/0x100
[   22.438580]  ? sidtab_context_to_sid+0x32/0x400
[   22.439979]  filemap_read+0xcd/0x3d0
[   22.440917]  xfs_file_buffered_read+0x4a/0xc0
[   22.441984]  xfs_file_read_iter+0x65/0xd0
[   22.442970]  __kernel_read+0x160/0x2e0
[   22.443921]  bprm_execve+0x21b/0x640
[   22.444809]  do_execveat_common.isra.0+0x1a8/0x220
[   22.446008]  __x64_sys_execve+0x2d/0x40
[   22.446920]  do_syscall_64+0x37/0x90
[   22.447773]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

This patch fixes this issue by getting vq from vblk, and removes
virtblk_init_hctx().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2b54e14535bc34bf649372060d518ec9f2b893b3; https://git.kernel.org/stable/c/8d12ec[PII_REDACTED]ee4463b11a63bd850bc09b5