USN-7791-3: linux-gcp-6.14 Ubuntu

CVSS: UnknownPublished

Published 06-10-2025Last modified 31-07-2026

Open JSON

Vulnerability summary

USN-7791-3 is a vulnerability in linux-gcp-6.14 Ubuntu with no CVSS score yet.

Overall risk

0/100

0100

Minimal · default modelHow is this calculated?

CVSS score

Not scored

010

No CVSS score recorded

EPSS score

Not scored

0%100%

No EPSS score yet

KEVNot listedIn no KEV catalog

RansomwareNone recordedNo known use recorded

Public exploits0No public exploits recorded

Advisory lineage

Upstream 4 · Downstream 0 · Related 4

CVE-2025-38477 CVE-2025-38500 CVE-2025-38617 CVE-2025-38618

Timeline

06-10-2025
PublishedVulnerability first disclosed.
31-07-2026
Last modifiedVulnerability information updated.

Description

linux-gcp, linux-gcp-6.14, linux-oem-6.14 vulnerabilities Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - Packet sockets; - Network traffic control; - VMware vSockets driver; - XFRM subsystem; (CVE-2025-38617, CVE-2025-38500, CVE-2025-38477, CVE-2025-38618)

CVSS metrics

Risk metrics not yet published.

EPSS trend

No EPSS score has been published for this record yet.

Known exploited

Compare KEV catalogs

Not in any of the 3 tracked catalogs.

Public exploits

0 found

No public exploits indexed.

Weaknesses

CWE · root cause

No weakness data has been published for this record.

Affected systems

Ubuntu2 products

linux-gcp-6.14< 6.14.0-1017.18~24.04.1
linux-oem-6.14< 6.14.0-1013.13

1 vendor · 2 products

References

5 links

ubuntu.com/security/notices/USN-7791-3Advisory
ubuntu.com/security/CVE-2025-38477REPORT
ubuntu.com/security/CVE-2025-38500REPORT
ubuntu.com/security/CVE-2025-38617REPORT
ubuntu.com/security/CVE-2025-38618REPORT

Related vulnerabilities

USN-7699-2ubuntulinux-hwe-6.14+11y ago20-08-2025 18:37linux-hwe-6.14, linux-oem-6.14 vulnerabilities Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - RISC-V architecture; - x86 architecture; - Buffer Sharing and Synchronization framework; - DMA engine subsystem; - GPU drivers; - HID subsystem; - IIO ADC drivers; - IIO subsystem; - InfiniBand drivers; - Input Device core drivers; - Network drivers; - Mellanox network drivers; - PHY drivers; - Voltage and Current Regulator drivers; - VideoCore services drivers; - USB Type-C Connector System Software Interface driver; - Xen hypervisor drivers; - EROFS file system; - Network file system (NFS) client; - File systems infrastructure; - SMB network file system; - Network traffic control; - io_uring subsystem; - Kernel command line parsing driver; - Scheduler infrastructure; - Memory management; - Networking core; - MAC80211 subsystem; - Management Component Transport Protocol (MCTP); - Netfilter; - Open vSwitch; - TLS protocol; - Wireless networking; - SOF drivers; (CVE-2025-38011, CVE-2025-38095, CVE-2025-37967, CVE-2025-38012, CVE-2025-38019, CVE-2025-37960, CVE-2025-37973, CVE-2025-37958, CVE-2025-38094, CVE-2025-37963, CVE-2025-37955, CVE-2025-38014, CVE-2025-38025, CVE-2025-37970, CVE-2025-37947, CVE-2025-37966, CVE-2025-37948, CVE-2025-38013, CVE-2025-37957, CVE-2025-38028, CVE-2025-37962, CVE-2025-38002, CVE-2025-37996, CVE-2025-37992, CVE-2025-37969, CVE-2025-38009, CVE-2025-38027, CVE-2025-38020, CVE-2025-38023, CVE-2025-38008, CVE-2025-38015, CVE-2025-37954, CVE-2025-38007, CVE-2025-38005, CVE-2025-37956, CVE-2025-37965, CVE-2025-37972, CVE-2025-38006, CVE-2025-37971, CVE-2025-38056, CVE-2025-37968, CVE-2025-38024, CVE-2025-37951, CVE-2025-38016, CVE-2025-38022, CVE-2025-37964, CVE-2025-37994, CVE-2025-37952, CVE-2025-37998, CVE-2025-37993, CVE-2025-38018, CVE-2025-38010, CVE-2025-37995, CVE-2025-38021, CVE-2025-37999, CVE-2025-37961, CVE-2025-37959, CVE-2025-37950, CVE-2025-37949)USN-7650-1ubuntulinux-oem-6.141y ago17-07-2025 15:44linux-oem-6.14 vulnerabilities Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - PA-RISC architecture; - PowerPC architecture; - S390 architecture; - x86 architecture; - Compute Acceleration Framework; - Ublk userspace block driver; - ARM SCMI message protocol; - GPU drivers; - IOMMU subsystem; - IRQ chip drivers; - Multiple devices driver; - Network drivers; - PCI subsystem; - PTP clock framework; - SPI subsystem; - BTRFS file system; - SMB network file system; - eXpress Data Path; - Universal MIDI packet (UMP) support module; - Tracing infrastructure; - Memory management; - IPv4 networking; - IPv6 networking; - Network traffic control; - AMD SoC Alsa drivers; - SoC Audio generic drivers; (CVE-2025-37899, CVE-2025-37905, CVE-2025-37916, CVE-2025-37935, CVE-2025-37923, CVE-2025-37906, CVE-2025-37929, CVE-2025-37907, CVE-2025-37909, CVE-2025-37910, CVE-2025-37921, CVE-2025-37927, CVE-2025-38216, CVE-2025-37914, CVE-2025-37928, CVE-2025-37915, CVE-2025-37990, CVE-2025-37917, CVE-2025-37936, CVE-2025-37946, CVE-2025-37934, CVE-2025-37894, CVE-2025-37898, CVE-2025-37911, CVE-2025-37912, CVE-2025-37920, CVE-2025-37926, CVE-2025-37919, CVE-2025-37900, CVE-2025-37908, CVE-2025-37924, CVE-2025-37974, CVE-2025-37901, CVE-2025-37903, CVE-2025-37891, CVE-2025-37922, CVE-2025-37991, CVE-2025-37930, CVE-2025-37896, CVE-2025-37897, CVE-2025-37913, CVE-2025-37895, CVE-2025-37933, CVE-2025-37904, CVE-2025-37931)USN-7618-1ubuntulinux-oem-6.141y ago04-07-2025 15:15linux-oem-6.14 vulnerabilities Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - Bluetooth drivers; - Netfilter; - Network traffic control; (CVE-2025-37890, CVE-2025-37918, CVE-2025-37932, CVE-2025-38000, CVE-2025-37997, CVE-2025-38001)CVE-2025-40181debianlinux+1030.21%11mo ago12-11-2025 21:56In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP When running as an SNP or TDX guest under KVM, force the legacy PCI hole, i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC via a forced variable MTRR range. In most KVM-based setups, legacy devices such as the HPET and TPM are enumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, and optionally a SystemMemory descriptor for an OperationRegion, e.g. if the device needs to be accessed via a Control Method. If a SystemMemory entry is present, then the kernel's ACPI driver will auto-ioremap the region so that it can be accessed at will. However, the ACPI spec doesn't provide a way to enumerate the memory type of SystemMemory regions, i.e. there's no way to tell software that a region must be mapped as UC vs. WB, etc. As a result, Linux's ACPI driver always maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86. The dedicated device drivers however, e.g. the HPET driver and TPM driver, want to map their associated memory as UC or WC, as accessing PCI devices using WB is unsupported. On bare metal and non-CoCO, the conflicting requirements "work" as firmware configures the PCI hole (and other device memory) to be UC in the MTRRs. So even though the ACPI mappings request WB, they are forced to UC- in the kernel's tracking due to the kernel properly handling the MTRR overrides, and thus are compatible with the drivers' requested WC/UC-. With force WB MTRRs on SNP and TDX guests, the ACPI mappings get their requested WB if the ACPI mappings are established before the dedicated driver code attempts to initialize the device. E.g. if acpi_init() runs before the corresponding device driver is probed, ACPI's WB mapping will "win", and result in the driver's ioremap() failing because the existing WB mapping isn't compatible with the requested WC/UC-. E.g. when a TPM is emulated by the hypervisor (ignoring the security implications of relying on what is allegedly an untrusted entity to store measurements), the TPM driver will request UC and fail: [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0 [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12 Note, the '0x2' and '0x0' values refer to "enum page_cache_mode", not x86's memtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC). E.g. tracing mapping requests for TPM TIS yields: Mapping TPM TIS with req_type = 0 WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460 Modules linked in: CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025 RIP: 0010:memtype_reserve+0x2ab/0x460 __ioremap_caller+0x16d/0x3d0 ioremap_cache+0x17/0x30 x86_acpi_os_ioremap+0xe/0x20 acpi_os_map_iomem+0x1f3/0x240 acpi_os_map_memory+0xe/0x20 acpi_ex_system_memory_space_handler+0x273/0x440 acpi_ev_address_space_dispatch+0x176/0x4c0 acpi_ex_access_region+0x2ad/0x530 acpi_ex_field_datum_io+0xa2/0x4f0 acpi_ex_extract_from_field+0x296/0x3e0 acpi_ex_read_data_from_field+0xd1/0x460 acpi_ex_resolve_node_to_value+0x2ee/0x530 acpi_ex_resolve_to_value+0x1f2/0x540 acpi_ds_evaluate_name_path+0x11b/0x190 acpi_ds_exec_end_op+0x456/0x960 acpi_ps_parse_loop+0x27a/0xa50 acpi_ps_parse_aml+0x226/0x600 acpi_ps_execute_method+0x172/0x3e0 acpi_ns_evaluate+0x175/0x5f0 acpi_evaluate_object+0x213/0x490 acpi_evaluate_integer+0x6d/0x140 acpi_bus_get_status+0x93/0x150 acpi_add_single_object+0x43a/0x7c0 acpi_bus_check_add+0x149/0x3a0 acpi_bus_check_add_1+0x16/0x30 acpi_ns_walk_namespace+0x22c/0x360 acpi_walk_namespace+0x15c/0x170 acpi_bus_scan+0x1dd/0x200 acpi_scan_init+0xe5/0x2b0 acpi_init+0x264/0x5b0 do_one_i ---truncated---CVE-2025-40300debianlinux+1530.35%1y ago11-09-2025 16:49In the Linux kernel, the following vulnerability has been resolved: x86/vmscape: Add conditional IBPB mitigation VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit. Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB. This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace. The intent is to integrate and optimize these cases post-embargo. [ dhansen: elaborate on suboptimal IBPB solution ]CVE-2025-39818debianlinux+950.15%1y ago16-09-2025 13:00In the Linux kernel, the following vulnerability has been resolved: HID: intel-thc-hid: intel-thc: Fix incorrect pointer arithmetic in I2C regs save Improper use of secondary pointer (&dev->i2c_subip_regs) caused kernel crash and out-of-bounds error: BUG: KASAN: slab-out-of-bounds in _regmap_bulk_read+0x449/0x510 Write of size 4 at addr ffff888136005dc0 by task kworker/u33:5/5107 CPU: 3 UID: 0 PID: 5107 Comm: kworker/u33:5 Not tainted 6.16.0+ #3 PREEMPT(voluntary) Workqueue: async async_run_entry_fn Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 print_report+0xd1/0x660 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? kasan_complete_mode_report_info+0x26/0x200 kasan_report+0xe1/0x120 ? _regmap_bulk_read+0x449/0x510 ? _regmap_bulk_read+0x449/0x510 __asan_report_store4_noabort+0x17/0x30 _regmap_bulk_read+0x449/0x510 ? __pfx__regmap_bulk_read+0x10/0x10 regmap_bulk_read+0x270/0x3d0 pio_complete+0x1ee/0x2c0 [intel_thc] ? __pfx_pio_complete+0x10/0x10 [intel_thc] ? __pfx_pio_wait+0x10/0x10 [intel_thc] ? regmap_update_bits_base+0x13b/0x1f0 thc_i2c_subip_pio_read+0x117/0x270 [intel_thc] thc_i2c_subip_regs_save+0xc2/0x140 [intel_thc] ? __pfx_thc_i2c_subip_regs_save+0x10/0x10 [intel_thc] [...] The buggy address belongs to the object at ffff888136005d00 which belongs to the cache kmalloc-rnd-12-192 of size 192 The buggy address is located 0 bytes to the right of allocated 192-byte region [ffff888136005d00, ffff888136005dc0) Replaced with direct array indexing (&dev->i2c_subip_regs[i]) to ensure safe memory access.