Cloudanix VulnDB

CVE-2025-68220

None

CVSS

—

EPSS

0.2%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding inconsistency in a network driver for certain Texas Instruments hardware can cause Linux systems to crash when they try to start their network connections.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Inconsistent return value from knav_dma_open_channel (NULL vs ERR_PTR) leads to invalid pointer dereference and alignment exception in knav_dma_close_channel during resource cleanup in the TI netcp driver.

Why it matters to the business

Affected systems using Keystone TI network hardware may crash during network interface bring-up, causing availability loss. The issue appears in Chainguard GitLab container images and upstream kernel; low EPSS and no KEV status indicate minimal active exploitation risk but stability concerns remain for embedded or server deployments 315 days after disclosure.

How an attack unfolds

Triggering network device initialization (such as during IP autoconfiguration) exercises the error path in knav_dma_open_channel. The resulting bad pointer is passed to netcp_free_navigator_resources and then knav_dma_close_channel, producing a kernel fault. No named threat actors or ransomware campaigns have been observed exploiting this flaw.

How to fix it

Upgrade affected Chainguard images (gitlab-cng-fips, gitlab-base-fips, gitlab-container-registry-fips, gitlab-elasticsearch-indexer-fips, gitlab-logger-fips, gitlab-shell-fips, gitlab-toolbox-fips) to 17.6.5-r0 or later. Apply Linux kernel commit af6b10a13fc0aee37df4a8292414cc055c263fa3 or an equivalent stable backport.

How to confirm the fix worked

Confirm package or kernel version matches a listed fixed release; reproduce network interface initialization on Keystone hardware and verify absence of alignment faults in knav_dma_close_channel.

Typical attack path

  1. Initiate network interface configuration or open
  2. Encounter failure inside knav_dma_open_channel
  3. Invoke netcp_free_navigator_resources on the erroneous return value
  4. Call knav_dma_close_channel with an invalid pointer
  5. Trigger alignment exception and kernel panic

How to detect it

Search kernel logs for alignment exceptions, faults at knav_dma_close_channel, calls from netcp_free_navigator_resources, and stack traces containing netcp_ndo_open or ip_auto_config on Keystone platforms.

  • knav_dma_close_channel+0x30/0x19c
  • Unhandled fault: alignment exception
  • netcp_free_navigator_resources+0x2c/0x28c
  • netcp_ndo_open+0x430/0x46c

What your security team should do

  • Patch all listed Chainguard GitLab FIPS images to 17.6.5-r0 immediately
  • Backport or update the Linux kernel to include commit af6b10a13fc0aee37df4a8292414cc055c263fa3
  • Test network bring-up in lab environments matching affected hardware
  • Add kernel oops monitoring for netcp-related functions

The record

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: netcp: Standardize knav_dma_open_channel to return NULL on error Make knav_dma_open_channel consistently return NULL on error instead of ERR_PTR. Currently the header include/linux/soc/ti/knav_dma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERR_PTR on failure, causing inconsistency in the users. This results in a crash in netcp_free_navigator_resources as followed (trimmed): Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] *pgd=80000800207003, *pmd=82ffda003, *pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knav_dma_close_channel+0x30/0x19c LR is at netcp_free_navigator_resources+0x2c/0x28c [... TRIM...] Call trace: knav_dma_close_channel from netcp_free_navigator_resources+0x2c/0x28c netcp_free_navigator_resources from netcp_ndo_open+0x430/0x46c netcp_ndo_open from __dev_open+0x114/0x29c __dev_open from __dev_change_flags+0x190/0x208 __dev_change_flags from netif_change_flags+0x1c/0x58 netif_change_flags from dev_change_flags+0x38/0xa0 dev_change_flags from ip_auto_config+0x2c4/0x11f0 ip_auto_config from do_one_initcall+0x58/0x200 do_one_initcall from kernel_init_freeable+0x1cc/0x238 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x38 [... TRIM...] Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcp_core.c so the impact is limited. Note, this change, in effect reverts commit 5b6cb43b4d62 ("net: ethernet: ti: netcp_core: return error while dma channel open issue"), but provides a less error prone implementation.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 3.18.0 5.4.302
Linux Kernel 4.12.0 5.4.302
Mageia:9 kernel 0 6.6.120-1.mga9
Mageia:9 kernel-linus 0 6.6.120-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.14-14.mga9
Mageia:9 kmod-xtables-addons 0 3.24-88.mga9

Related vulnerabilities