Skip to content
Heist/ feed
Back to feed
UnratedFix available

idpf: detach and close netdevs while handling a reset

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: idpf: detach and close netdevs while handling a reset Protect the reset path from callbacks by setting the netdevs to detached state and close any netdevs in UP state until the reset handling has completed. During a reset, the driver will de-allocate resources for the vport, and there is no guarantee that those will recover, which is why the existing vport_ctrl_lock does not provide sufficient protection. idpf_detach_and_close() is called right before reset handling. If the reset handling succeeds, the netdevs state is recovered via call to idpf_attach_and_open(). If the reset handling fails the netdevs remain down. The detach/down calls are protected with RTNL lock to avoid racing with callbacks. On the recovery side the attach can be done without holding the RTNL lock as there are no callbacks expected at that point, due to detach/close always being done first in that flow. The previous logic restoring the netdevs state based on the IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is still being used to restore the state of the netdevs following the reset, but has no use outside of the reset handling flow. idpf_init_hard_reset() is converted to void, since it was used as such and there is no error handling being done based on its return value. Before this change, invoking hard and soft resets simultaneously will cau

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.80, 6.18.6
CVEs
CVE-2026-22981
Confirmed fixed CVEs
Not specified
Updated in this feed
8 Nov 2026, 01:59 UTC · Revision 1

Source evidence

idpf: detach and close netdevs while handling a reset

core-osv · Original source

Published 23 Jan 2026, 15:24 UTC

In the Linux kernel, the following vulnerability has been resolved: idpf: detach and close netdevs while handling a reset Protect the reset path from callbacks by setting the netdevs to detached state and close any netdevs in UP state until the reset handling has completed. During a reset, the driver will de-allocate resources for the vport, and there is no guarantee that those will recover, which is why the existing vport_ctrl_lock does not provide sufficient protection. idpf_detach_and_close() is called right before reset handling. If the reset handling succeeds, the netdevs state is recovered via call to idpf_attach_and_open(). If the reset handling fails the netdevs remain down. The detach/down calls are protected with RTNL lock to avoid racing with callbacks. On the recovery side the attach can be done without holding the RTNL lock as there are no callbacks expected at that point, due to detach/close always being done first in that flow. The previous logic restoring the netdevs state based on the IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is still being used to restore the state of the netdevs following the reset, but has no use outside of the reset handling flow. idpf_init_hard_reset() is converted to void, since it was used as such and there is no error handling being done based on its return value. Before this change, invoking hard and soft resets simultaneously will cau

osv:CVE-2026-22981

Kernel

Fixed versions: 6.12.80, 6.18.6

Complete source record
{
  "id": "fc130c0d4536593227ff14a3fd7030e27744d4032c9bb479774393885ac0f75a",
  "url": "https://osv.dev/vulnerability/CVE-2026-22981",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "idpf: detach and close netdevs while handling a reset",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: idpf: detach and close netdevs while handling a reset Protect the reset path from callbacks by setting the netdevs to detached state and close any netdevs in UP state until the reset handling has completed. During a reset, the driver will de-allocate resources for the vport, and there is no guarantee that those will recover, which is why the existing vport_ctrl_lock does not provide sufficient protection. idpf_detach_and_close() is called right before reset handling. If the reset handling succeeds, the netdevs state is recovered via call to idpf_attach_and_open(). If the reset handling fails the netdevs remain down. The detach/down calls are protected with RTNL lock to avoid racing with callbacks. On the recovery side the attach can be done without holding the RTNL lock as there are no callbacks expected at that point, due to detach/close always being done first in that flow. The previous logic restoring the netdevs state based on the IDPF_VPORT_UP_REQUESTED flag in the init task is not needed anymore, hence the removal of idpf_set_vport_state(). The IDPF_VPORT_UP_REQUESTED is still being used to restore the state of the netdevs following the reset, but has no use outside of the reset handling flow. idpf_init_hard_reset() is converted to void, since it was used as such and there is no error handling being done based on its return value. Before this change, invoking hard and soft resets simultaneously will cau",
    "evidence": "osv:CVE-2026-22981",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.80",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.6",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "CVE-2026-22981",
      "aliases": [
        "CVE-2026-22981"
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "0fe45467a1041ea3657a7fa3a791c84c104fbd34"
                },
                {
                  "fixed": "9ad3d0836d8bc1a0f0b4bf56efc56312a9e64b97"
                },
                {
                  "fixed": "ac122f5fb050903b3d262001562c452be95eaf70"
                },
                {
                  "fixed": "2e281e1155fc476c571c0bd2ffbfe28ab829a5c3"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-22981.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.80"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.6"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-22981.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:52.773098440Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/2e281e1155fc476c571c0bd2ffbfe28ab829a5c3",
        "https://git.kernel.org/stable/c/9ad3d0836d8bc1a0f0b4bf56efc56312a9e64b97",
        "https://git.kernel.org/stable/c/ac122f5fb050903b3d262001562c452be95eaf70",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/22xxx/CVE-2026-22981.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-22981",
        "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/2026/22xxx/CVE-2026-22981.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-22981",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 521571,
  "published_at": "2026-01-23T15:24:03.772+00:00"
}