FKIE_CVE-2026-74691

Vulnerability from fkie_nvd - Published: 2026-08-22 16:16 - Updated: 2026-10-14 13:10
Severity
8.8 (High) - CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Tear down DMA paths before stopping the rings tbnet_tear_down() stops both rings and frees their frame buffers before calling tb_xdomain_disable_paths(). tb_ring_stop() zeroes the ring's descriptor base and tbnet_free_buffers() unmaps and frees the pages the frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's 'pending' bit, anything still in flight has nowhere to drain to. The teardown sequence has been in this order since the driver was added. The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable DMA paths only after rings are enabled") moved the path enable to the end of tbnet_connected_work() and documented why: /* Both logins successful so enable the rings, high-speed DMA * paths and start the network device queue. * * Note we enable the DMA paths last to make sure we have primed * the Rx ring before any incoming packets are allowed to * arrive. */ Teardown was never updated to match, so the rings and the paths now come down in the same order they go up instead of in reverse. On an ASMedia ASM4242 host router the 'pending' bit then never clears: every teardown burns the full 500 ms timeout and __tb_path_deactivate_hop() returns -ETIMEDOUT. Raising the timeout to 5 s does not help, so the hop is not slow to drain, it never drains at all. The failure is invisible above the thunderbolt core. __tb_path_deactivate_hops() is void and only calls tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() and __tb_disconnect_xdomain_paths() are void as well, and tb_disconnect_xdomain_paths() ends in an unconditional "return 0". So tb_xdomain_disable_paths() reports success and the netdev_warn() below it never fires. Repeated teardowns eventually take the XDomain control channel down, after which the peer node is gone and only a power cycle brings the controller back. Deactivating the paths first fixes it. Measured with kretprobes on a stock v6.17 tree with no other patches applied, on a link that was up and had just carried traffic: before: __tb_path_deactivate_hop() returns 0 for the first hop, then -ETIMEDOUT for the second 500335 us later after: 0 for both, 525 us apart Alternating the two orderings ABBA over three load levels, four teardowns per arm: every teardown failed before the change (21 of 21 that ran), none failed after (0 of 24). The before arms ran short because the link died partway through. The same split shows up when the interface is enslaved to a bond instead of just brought down, which is how I ran into this in the first place. Throughput and latency after the change are unchanged. Hosts whose routers drain the hop despite the stale descriptor base see no functional difference, since the paths end up deactivated either way.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/0da9a6d27155ad072dd76db8cd637feead99a0e0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/103a9b663ac1cacb8465aeff18f84a247154a562
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/4dd71cb0d23d40cb58fe4261c7bd183dca66caa0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/68bf02b6b4ad3f748c6db71fd77b6c0402d252f4
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7cce39109206bc5497e0953806563644b88bfc44
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9a482b2b117e5fa656b6d24fc01799e8ac2d4368
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/b5a21615f627c48dafaa6ef82a34a5b97a4352aa
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/thunderbolt/main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "7cce39109206bc5497e0953806563644b88bfc44",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "0da9a6d27155ad072dd76db8cd637feead99a0e0",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "b5a21615f627c48dafaa6ef82a34a5b97a4352aa",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "103a9b663ac1cacb8465aeff18f84a247154a562",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "4dd71cb0d23d40cb58fe4261c7bd183dca66caa0",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "9a482b2b117e5fa656b6d24fc01799e8ac2d4368",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            },
            {
              "lessThan": "68bf02b6b4ad3f748c6db71fd77b6c0402d252f4",
              "status": "affected",
              "version": "e69b6c02b4c3b8d03be7136f90dd9551ad5a5a5e",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/thunderbolt/main.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.15"
            },
            {
              "lessThan": "4.15",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.216",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.183",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.152",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.104",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.45",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: thunderbolt: Tear down DMA paths before stopping the rings\n\ntbnet_tear_down() stops both rings and frees their frame buffers before\ncalling tb_xdomain_disable_paths().  tb_ring_stop() zeroes the ring\u0027s\ndescriptor base and tbnet_free_buffers() unmaps and frees the pages the\nframes sit in, so by the time __tb_path_deactivate_hop() polls the hop\u0027s\n\u0027pending\u0027 bit, anything still in flight has nowhere to drain to.\n\nThe teardown sequence has been in this order since the driver was added.\nThe setup path has not: commit ff7cd07f3064 (\"net: thunderbolt: Enable\nDMA paths only after rings are enabled\") moved the path enable to the end\nof tbnet_connected_work() and documented why:\n\n\t/* Both logins successful so enable the rings, high-speed DMA\n\t * paths and start the network device queue.\n\t *\n\t * Note we enable the DMA paths last to make sure we have primed\n\t * the Rx ring before any incoming packets are allowed to\n\t * arrive.\n\t */\n\nTeardown was never updated to match, so the rings and the paths now come\ndown in the same order they go up instead of in reverse.\n\nOn an ASMedia ASM4242 host router the \u0027pending\u0027 bit then never clears:\nevery teardown burns the full 500 ms timeout and\n__tb_path_deactivate_hop() returns -ETIMEDOUT.  Raising the timeout to\n5 s does not help, so the hop is not slow to drain, it never drains\nat all.\n\nThe failure is invisible above the thunderbolt core.\n__tb_path_deactivate_hops() is void and only calls tb_port_warn();\ntb_path_deactivate(), tb_tunnel_deactivate() and\n__tb_disconnect_xdomain_paths() are void as well, and\ntb_disconnect_xdomain_paths() ends in an unconditional \"return 0\".  So\ntb_xdomain_disable_paths() reports success and the netdev_warn() below\nit never fires.  Repeated teardowns eventually take the XDomain control\nchannel down, after which the peer node is gone and only a power cycle\nbrings the controller back.\n\nDeactivating the paths first fixes it.  Measured with kretprobes on a\nstock v6.17 tree with no other patches applied, on a link that was up\nand had just carried traffic:\n\n  before: __tb_path_deactivate_hop() returns 0 for the first hop, then\n          -ETIMEDOUT for the second 500335 us later\n  after:  0 for both, 525 us apart\n\nAlternating the two orderings ABBA over three load levels, four\nteardowns per arm: every teardown failed before the change (21 of 21\nthat ran), none failed after (0 of 24).  The before arms ran short\nbecause the link died partway through.  The same split shows up when\nthe interface is enslaved to a bond instead of just brought down, which\nis how I ran into this in the first place.  Throughput and latency after\nthe change are unchanged.\n\nHosts whose routers drain the hop despite the stale descriptor base see\nno functional difference, since the paths end up deactivated either way."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nnet: thunderbolt: Desactivar las rutas DMA antes de detener los anillos\n\ntbnet_tear_down() detiene ambos anillos y libera sus b\u00faferes de trama antes de llamar a tb_xdomain_disable_paths(). tb_ring_stop() pone a cero la base del descriptor del anillo y tbnet_free_buffers() desmapea y libera las p\u00e1ginas en las que residen las tramas, as\u00ed que para cuando __tb_path_deactivate_hop() sondea el bit \u0027pending\u0027 del salto, cualquier cosa a\u00fan en tr\u00e1nsito no tiene a d\u00f3nde drenar.\n\nLa secuencia de desactivaci\u00f3n ha estado en este orden desde que se a\u00f1adi\u00f3 el controlador. La ruta de configuraci\u00f3n no: el commit ff7cd07f3064 (\u0027net: thunderbolt: Habilitar rutas DMA solo despu\u00e9s de que los anillos est\u00e9n habilitados\u0027) movi\u00f3 la habilitaci\u00f3n de la ruta al final de tbnet_connected_work() y document\u00f3 por qu\u00e9:\n\n\t/* Ambos inicios de sesi\u00f3n exitosos, as\u00ed que habilite los anillos, las rutas DMA\n\t * de alta velocidad y arranque la cola del dispositivo de red.\n\t *\n\t * Tenga en cuenta que habilitamos las rutas DMA al final para asegurarnos de haber cebado\n\t * el anillo Rx antes de que se permita la llegada de cualquier paquete\n\t * entrante.\n\t */\n\nLa desactivaci\u00f3n nunca se actualiz\u00f3 para coincidir, as\u00ed que los anillos y las rutas ahora se desactivan en el mismo orden en que se activan en lugar de en orden inverso.\n\nEn un router host ASMedia ASM4242, el bit \u0027pending\u0027 nunca se borra: cada desactivaci\u00f3n consume el tiempo de espera completo de 500 ms y __tb_path_deactivate_hop() devuelve -ETIMEDOUT. Aumentar el tiempo de espera a 5 s no ayuda, as\u00ed que el salto no es lento para drenar, nunca drena en absoluto.\n\nEl fallo es invisible por encima del n\u00facleo thunderbolt. __tb_path_deactivate_hops() es void y solo llama a tb_port_warn(); tb_path_deactivate(), tb_tunnel_deactivate() y __tb_disconnect_xdomain_paths() tambi\u00e9n son void, y tb_disconnect_xdomain_paths() termina en un \u0027return 0\u0027 incondicional. As\u00ed que tb_xdomain_disable_paths() reporta \u00e9xito y el netdev_warn() debajo de \u00e9l nunca se activa. Desactivaciones repetidas eventualmente desactivan el canal de control XDomain, despu\u00e9s de lo cual el nodo par desaparece y solo un ciclo de encendido devuelve el controlador.\n\nDesactivar las rutas primero lo soluciona. Medido con kretprobes en un \u00e1rbol v6.17 est\u00e1ndar sin otros parches aplicados, en un enlace que estaba activo y acababa de transportar tr\u00e1fico:\n\n  antes: __tb_path_deactivate_hop() devuelve 0 para el primer salto, luego -ETIMEDOUT para el segundo 500335 us despu\u00e9s\n  despu\u00e9s: 0 para ambos, con 525 us de diferencia\n\nAlternando los dos \u00f3rdenes ABBA sobre tres niveles de carga, cuatro desactivaciones por brazo: cada desactivaci\u00f3n fall\u00f3 antes del cambio (21 de 21 que se ejecutaron), ninguna fall\u00f3 despu\u00e9s (0 de 24). Los brazos \u0027antes\u0027 se acortaron porque el enlace muri\u00f3 a mitad de camino. La misma divisi\u00f3n aparece cuando la interfaz se esclaviza a un bond en lugar de simplemente desactivarse, que es como me encontr\u00e9 con esto en primer lugar. El rendimiento y la latencia despu\u00e9s del cambio no han cambiado.\n\nLos hosts cuyos routers drenan el salto a pesar de la base de descriptor obsoleta no ven ninguna diferencia funcional, ya que las rutas terminan desactivadas de cualquier manera."
    }
  ],
  "id": "CVE-2026-74691",
  "lastModified": "2026-10-14T13:10:00.187",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "ADJACENT_NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 8.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-08-22T16:16:43.527",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0da9a6d27155ad072dd76db8cd637feead99a0e0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/103a9b663ac1cacb8465aeff18f84a247154a562"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4dd71cb0d23d40cb58fe4261c7bd183dca66caa0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/68bf02b6b4ad3f748c6db71fd77b6c0402d252f4"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7cce39109206bc5497e0953806563644b88bfc44"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9a482b2b117e5fa656b6d24fc01799e8ac2d4368"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b5a21615f627c48dafaa6ef82a34a5b97a4352aa"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.