Skip to content
Heist/ feed
Back to feed
HighFix available

ice: fix NULL access of tx->in_use in ice_ll_ts_intr

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the "low latency" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.46, 6.16.6
CVEs
CVE-2025-39854
Confirmed fixed CVEs
Not specified
Updated in this feed
3 Nov 2026, 17:17 UTC · Revision 1

Source evidence

ice: fix NULL access of tx->in_use in ice_ll_ts_intr

core-osv · Original source

Published 19 Sept 2025, 15:26 UTC

In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the "low latency" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.

osv:CVE-2025-39854

Kernel

Fixed versions: 6.12.46, 6.16.6

Complete source record
{
  "id": "0aaa8ab57aaa2ef2c797de8b4676d3d32dc472ceac97d18b2cdc5b58e1e69072",
  "url": "https://osv.dev/vulnerability/CVE-2025-39854",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "ice: fix NULL access of tx->in_use in ice_ll_ts_intr",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL access of tx->in_use in ice_ll_ts_intr Recent versions of the E810 firmware have support for an extra interrupt to handle report of the \"low latency\" Tx timestamps coming from the specialized low latency firmware interface. Instead of polling the registers, software can wait until the low latency interrupt is fired. This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as it uses the same \"ready\" bitmap to track which Tx timestamps complete. Unfortunately, the ice_ll_ts_intr() function does not check if the tracker is initialized before its first access. This results in NULL dereference or use-after-free bugs similar to the issues fixed in the ice_ptp_ts_irq() function. Fix this by only checking the in_use bitmap (and other fields) if the tracker is marked as initialized. The reset flow will clear the init field under lock before it tears the tracker down, thus preventing any use-after-free or NULL access.",
    "evidence": "osv:CVE-2025-39854",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.46",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.16.6",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2025-39854",
      "aliases": [
        "CVE-2025-39854"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "82e71b226e0ef770d7bc143701c8b4960b4eb3d5"
                },
                {
                  "fixed": "2cde98a02da958357fe240a6ba269b69d913b6ba"
                },
                {
                  "fixed": "923c267bdbb64f65bc1149d184efcf8b047d7d64"
                },
                {
                  "fixed": "f6486338fde3f04ed0ec59fe67a69a208c32734f"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-39854.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.8.0"
                },
                {
                  "fixed": "6.12.46"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.16.6"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-39854.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:30.620514504Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/2cde98a02da958357fe240a6ba269b69d913b6ba",
        "https://git.kernel.org/stable/c/923c267bdbb64f65bc1149d184efcf8b047d7d64",
        "https://git.kernel.org/stable/c/f6486338fde3f04ed0ec59fe67a69a208c32734f",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/39xxx/CVE-2025-39854.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-39854",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/39xxx/CVE-2025-39854.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2025-39854",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 497769,
  "published_at": "2025-09-19T15:26:25.989+00:00"
}