huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2025-21858: kernel: geneve: Fix use-after-free in geneve_find_dev().
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H)
Public date: 2025-03-12T00:00:00+00:00

A use-after-free vulnerability exists in the Linux kernel. When dev_net is dismantled, the geneve_exit_batch_rtnl() function calls unregister_netdevice_queue() for each device in the network namespace. Later, when the device is freed, it is still linked to the backend UDP socket in the network namespace.


Affected upstream versions: 4.2
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.130, 6.12.17, 6.13.5, 6.14, 6.6.80
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d5e86e27de0936f3cb0a299ce519d993e9cf3886
CVE-2025-21861: kernel: mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-03-12T00:00:00+00:00

A vulnerability was found in the Linux kernel's memory migration system in the migrate_device_finalize() function, where a folio that should be freed is erroneously added back into the Least Recently Used (LRU) list. This issue can lead to memory corruption caused by a use-after-free issue when a previously freed folio is reaccessed, leading to system instability or potential denial of service.


Affected upstream versions: 4.14
Fixed upstream versions: 0, 5.10.245, 5.15.194, 5.4.300, 6.1.155, 6.12.17, 6.13.5, 6.14, 6.6.109
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 61fa824e304ed162fe965f64999068e6fcff2059
CVE-2025-21863: kernel: io_uring: prevent opcode speculation
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-03-12T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

io_uring: prevent opcode speculation

sqe->opcode is used for different tables, make sure we santitise it
against speculations.


Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.259, 5.15.209, 6.1.175, 6.12.17, 6.13.5, 6.14, 6.6.80
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 87e9eef43c758da267f6332678058a79764c7eba
CVE-2025-21864: kernel: tcp: drop secpath at the same time as we currently drop dst
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-03-12T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

tcp: drop secpath at the same time as we currently drop dst

Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while
running tests that boil down to:
 - create a pair of netns
 - run a basic TCP test over ipcomp6
 - delete the pair of netns

The xfrm_state found on spi_byaddr was not deleted at the time we
delete the netns, because we still have a reference on it. This
lingering reference comes from a secpath (which holds a ref on the
xfrm_state), which is still attached to an skb. This skb is not
leaked, it ends up on sk_receive_queue and then gets defer-free'd by
skb_attempt_defer_free.

The problem happens when we defer freeing an skb (push it on one CPU's
defer_list), and don't flush that list before the netns is deleted. In
that case, we still have a reference on the xfrm_state that we don't
expect at this point.

We already drop the skb's dst in the TCP receive path when it's no
longer needed, so let's also drop the secpath. At this point,
tcp_filter has already called into the LSM hooks that may require the
secpath, so it should not be needed anymore. However, in some of those
places, the MPTCP extension has just been attached to the skb, so we
cannot simply drop all extensions.

Statement: The bug is that memory leak could happen. The security impact is limited, because no kernel panic or other errors that could be used for privileges escalation or other attack. For triggering the bug user have to use ipcomp6 and MPTCP extension.

Affected upstream versions: 5.19
Fixed upstream versions: 0, 6.1.130, 6.12.17, 6.13.5, 6.14, 6.6.80
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 87858bbf21da239ace300d61dd209907995c0491
CVE-2025-21867: kernel: bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-03-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

bpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()

KMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. The
cause of the issue was that eth_skb_pkt_type() accessed skb's data
that didn't contain an Ethernet header. This occurs when
bpf_prog_test_run_xdp() passes an invalid value as the user_data
argument to bpf_test_init().

Fix this by returning an error when user_data is less than ETH_HLEN in
bpf_test_init(). Additionally, remove the check for "if (user_size >
size)" as it is unnecessary.

[1]
BUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]
BUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165
 eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]
 eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165
 __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635
 xdp_recv_frames net/bpf/test_run.c:272 [inline]
 xdp_test_run_batch net/bpf/test_run.c:361 [inline]
 bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390
 bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318
 bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371
 __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777
 __do_sys_bpf kernel/bpf/syscall.c:5866 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5864 [inline]
 __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864
 x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
 free_pages_prepare mm/page_alloc.c:1056 [inline]
 free_unref_page+0x156/0x1320 mm/page_alloc.c:2657
 __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838
 bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline]
 ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235
 bpf_map_free kernel/bpf/syscall.c:838 [inline]
 bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310
 worker_thread+0xedf/0x1550 kernel/workqueue.c:3391
 kthread+0x535/0x6b0 kernel/kthread.c:389
 ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

CPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014


Affected upstream versions: 5.18
Fixed upstream versions: 0, 6.1.130, 6.12.17, 6.13.5, 6.14, 6.6.80
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f615fccfc689cb48977d275ac2e391297b52392b
CVE-2025-21883: kernel: ice: Fix deinitializing VF in error path
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-03-27T00:00:00+00:00

A use-after-free vulnerability was discovered in the Linux kernel's Ethernet Connection E800 Series driver, which is responsible for managing network connections. This issue occurs when an attacker with local privileges intentionally triggers this error path, causing an error to occur in the ice_ena_vfs() function, a critical part of this driver.

Statement: This vulnerability specifically affects systems that are using the Ethernet Connection E800 Series driver, which is responsible for managing network connections. The problem arises because this driver has a specific error path that, if triggered, could cause a system crash or allow an attacker to gain elevated privileges.

Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.12.18, 6.13.6, 6.14, 6.6.81
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3c01102bec9592928e6b155da41cfcd5d25a2066
CVE-2025-21887: kernel: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-03-27T00:00:00+00:00

A use after free vulnerability exists in the linux kernel such that dput(upper) is being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote().


Affected upstream versions: 5.10.188 < 5.10.247, 5.15.121 < 5.15.179, 6.1.39 < 6.1.130, 6.3.13 < 6.4, 6.4.4 < 6.5, 6.5
Fixed upstream versions: 0, 5.10.247, 5.15.179, 6.1.130, 6.12.18, 6.13.6, 6.14, 6.4, 6.5, 6.6.81
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f77618291836168eca99e89cd175256f928f5e64
CVE-2025-21893: kernel: keys: Fix UAF in key_put()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-03-31T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

keys: Fix UAF in key_put()

Once a key's reference count has been reduced to 0, the garbage collector
thread may destroy it at any time and so key_put() is not allowed to touch
the key after that point.  The most key_put() is normally allowed to do is
to touch key_gc_work as that's a static global variable.

However, in an effort to speed up the reclamation of quota, this is now
done in key_put() once the key's usage is reduced to 0 - but now the code
is looking at the key after the deadline, which is forbidden.

Fix this by using a flag to indicate that a key can be gc'd now rather than
looking at the key's refcount in the garbage collector.


Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.12.21, 6.13.9, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6afe2ea2daec156bd94ad2c5a6f4f4c48240dcd3
CVE-2025-21902: kernel: acpi: typec: ucsi: Introduce a ->poll_cci method
Component: kernel
Severity: Low
CWE: CWE-662 (Improper Synchronization)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2025-04-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

acpi: typec: ucsi: Introduce a ->poll_cci method

For the ACPI backend of UCSI the UCSI "registers" are just a memory copy
of the register values in an opregion. The ACPI implementation in the
BIOS ensures that the opregion contents are synced to the embedded
controller and it ensures that the registers (in particular CCI) are
synced back to the opregion on notifications. While there is an ACPI call
that syncs the actual registers to the opregion there is rarely a need to
do this and on some ACPI implementations it actually breaks in various
interesting ways.

The only reason to force a sync from the embedded controller is to poll
CCI while notifications are disabled. Only the ucsi core knows if this
is the case and guessing based on the current command is suboptimal, i.e.
leading to the following spurious assertion splat:

WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1
Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023
Workqueue: events_long ucsi_init_work [typec_ucsi]
RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
Call Trace:
 <TASK>
 ucsi_init_work+0x3c/0xac0 [typec_ucsi]
 process_one_work+0x179/0x330
 worker_thread+0x252/0x390
 kthread+0xd2/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Thus introduce a ->poll_cci() method that works like ->read_cci() with an
additional forced sync and document that this should be used when polling
with notifications disabled. For all other backends that presumably don't
have this issue use the same implementation for both methods.


Affected upstream versions: 6.12.5 < 6.12.19, 6.13
Fixed upstream versions: 0, 6.12.19, 6.13.7, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 012b98cdb54c7d47743ee7fc402fa23f2d90529a
CVE-2025-21905: kernel: wifi: iwlwifi: limit printed string from FW file
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-04-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: limit printed string from FW file

There's no guarantee here that the file is always with a
NUL-termination, so reading the string may read beyond the
end of the TLV. If that's the last TLV in the file, it can
perhaps even read beyond the end of the file buffer.

Fix that by limiting the print format to the size of the
buffer we have.


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.131, 6.12.19, 6.13.7, 6.14, 6.6.83
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 38f0d398b6d7640d223db69df022c4a232f24774
CVE-2025-21919: kernel: sched/fair: Fix potential memory corruption in child_cfs_rq_on_list
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-04-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Fix potential memory corruption in child_cfs_rq_on_list

child_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.
This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,
making the conversion invalid and potentially leading to memory
corruption. Depending on the relative positions of leaf_cfs_rq_list and
the task group (tg) pointer within the struct, this can cause a memory
fault or access garbage data.

The issue arises in list_add_leaf_cfs_rq, where both
cfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the same
leaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.

This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the main
conditional in child_cfs_rq_on_list. This ensures that the container_of
operation will convert a correct cfs_rq struct.

This check is sufficient because only cfs_rqs on the same CPU are added
to the list, so verifying the 'prev' pointer against the current rq's list
head is enough.

Fixes a potential memory corruption issue that due to current struct
layout might not be manifesting as a crash but could lead to unpredictable
behavior when the layout changes.

Statement: The security impact is limited, because there is no known vector of attack. The description of patch says: "Fixes a potential memory corruption issue that due to current struct layout might not be manifesting as a crash but could lead to unpredictable behavior when the layout changes". Keeping CVSS score 7.0 with attack complexity high. Plan to fix it.

Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.179, 6.1.131, 6.12.19, 6.13.7, 6.14, 6.6.83
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5cb300dcdd27e6a351ac02541e0231261c775852
CVE-2025-21920: kernel: vlan: enforce underlying device type
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-04-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

vlan: enforce underlying device type

Currently, VLAN devices can be created on top of non-ethernet devices.

Besides the fact that it doesn't make much sense, this also causes a
bug which leaks the address of a kernel function to usermode.

When creating a VLAN device, we initialize GARP (garp_init_applicant)
and MRP (mrp_init_applicant) for the underlying device.

As part of the initialization process, we add the multicast address of
each applicant to the underlying device, by calling dev_mc_add.

__dev_mc_add uses dev->addr_len to determine the length of the new
multicast address.

This causes an out-of-bounds read if dev->addr_len is greater than 6,
since the multicast addresses provided by GARP and MRP are only 6
bytes long.

This behaviour can be reproduced using the following commands:

ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo
ip l set up dev gretest
ip link add link gretest name vlantest type vlan id 100

Then, the following command will display the address of garp_pdu_rcv:

ip maddr show | grep 01:80:c2:00:00:21

Fix the bug by enforcing the type of the underlying device during VLAN
device initialization.


Affected upstream versions: 2.6.35
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.131, 6.12.19, 6.13.7, 6.14, 6.6.83
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7f1564b2b2072b7aa1ac75350e9560a07c7a44fd
CVE-2025-21926: kernel: net: gso: fix ownership in __udp_gso_segment
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-04-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: gso: fix ownership in __udp_gso_segment

In __udp_gso_segment the skb destructor is removed before segmenting the
skb but the socket reference is kept as-is. This is an issue if the
original skb is later orphaned as we can hit the following bug:

  kernel BUG at ./include/linux/skbuff.h:3312!  (skb_orphan)
  RIP: 0010:ip_rcv_core+0x8b2/0xca0
  Call Trace:
   ip_rcv+0xab/0x6e0
   __netif_receive_skb_one_core+0x168/0x1b0
   process_backlog+0x384/0x1100
   __napi_poll.constprop.0+0xa1/0x370
   net_rx_action+0x925/0xe50

The above can happen following a sequence of events when using
OpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an
OVS_ACTION_ATTR_OUTPUT action:

1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb
   goes through queue_gso_packets and then __udp_gso_segment, where its
   destructor is removed.
2. The segments' data are copied and sent to userspace.
3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the
   same original skb is sent to its path.
4. If it later hits skb_orphan, we hit the bug.

Fix this by also removing the reference to the socket in
__udp_gso_segment.

Statement: If UDP fragmentation offload being used (that allows a device to fragment an oversized UDP datagram into multiple IPv fragments), then this bug could happen. The bug happens when skb_orphan function later being called. It is complex to trigger the bug (few conditions should happen simultaneously) and only local user can trigger it.

Affected upstream versions: 4.18
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.131, 6.12.19, 6.13.7, 6.14, 6.6.83
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9f28205ddb76e86cac418332e952241d85fed0dc
CVE-2025-21927: kernel: nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()
Component: kernel
Severity: Important
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
CVSS v3: 8 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-04-01T00:00:00+00:00

An unchecked buffer bounds flaw was found in the Linux kernel's NVMe TCP Fabrics driver. An attacker with the ability to send a crafted packet to an affected NVMe host could exploit this flaw to alter kernel memory, leading to an escalation of privileges or a compromise of system integrity or stability.

Statement: This flaw results from an improper bounds check, which an attacker could exploit by sending a packet with a too-large header. The driver processing that header will then both read beyond the bounds of the buffer it has allocated, and will also alter memory outside of the buffer when it writes the result of digest calculations. An attacker could thus read otherwise inaccessible kernel memory, causing a denial of service or exfiltrating sensitive data, or write out of bounds, which could lead to an escalation of privileges.
While NVMe over fabric is typically used in the context of a single system, Red Hat's assessment suggests an Attack Vector of Adjacent. This is due to the possibility of NVMe being used as a storage solution for a cluster or datacenter.
The NVMe/TCP driver in RHEL 8 was released as a Technology Preview feature and was never considered stable or fully supported. Therefore, RHEL 8 is out of support scope for this CVE.

Affected upstream versions: 5.0
Fixed upstream versions: 0, 6.12.19, 6.13.7, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9fbc953d6b38bc824392e01850f0aeee3b348722
CVE-2025-21928: kernel: HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-04-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()

The system can experience a random crash a few minutes after the driver is
removed. This issue occurs due to improper handling of memory freeing in
the ishtp_hid_remove() function.

The function currently frees the `driver_data` directly within the loop
that destroys the HID devices, which can lead to accessing freed memory.
Specifically, `hid_destroy_device()` uses `driver_data` when it calls
`hid_ishtp_set_feature()` to power off the sensor, so freeing
`driver_data` beforehand can result in accessing invalid memory.

This patch resolves the issue by storing the `driver_data` in a temporary
variable before calling `hid_destroy_device()`, and then freeing the
`driver_data` after the device is destroyed.

Statement: Triggering this vulnerability requires loading and unloading kernel modules, specifically triggering the removal of the `intel-ish-hid` driver. The loading and unloading of kernel drivers requires elevated privileges (e.g. `CAP_SYS_MODULE`) and cannot be done by a regular, unprivileged user.

Affected upstream versions: 4.9
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.131, 6.12.19, 6.13.7, 6.14, 6.6.83
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0c1fb475ef999d6c22fc3f963fdf20cb3ed1b03d