CVE-2025-71152 (GCVE-0-2025-71152)

Vulnerability from cvelistv5 – Published: 2026-01-23 14:25 – Updated: 2026-05-11 21:55
VLAI
Title
net: dsa: properly keep track of conduit reference
Summary
In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command "before" and "after" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not make user port errors fatal"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version
Linux Linux Affected: 83c0afaec7b730b16c518aecc8e6246ec91b265e , < ec2b34acb1894cfc10ed22d8277ca4f11e9f4b23 (git)
Affected: 83c0afaec7b730b16c518aecc8e6246ec91b265e , < b358fc6ff3b35a29f7f677da1c67af67d0d560cb (git)
Affected: 83c0afaec7b730b16c518aecc8e6246ec91b265e , < 0e766b77ba5093583dfe609fae0aa1545c46dbbd (git)
Affected: 83c0afaec7b730b16c518aecc8e6246ec91b265e , < 06e219f6a706c367c93051f408ac61417643d2f9 (git)
Create a notification for this product.
Linux Linux Affected: 4.8
Unaffected: 0 , < 4.8 (semver)
Unaffected: 6.6.130 , ≤ 6.6.* (semver)
Unaffected: 6.12.78 , ≤ 6.12.* (semver)
Unaffected: 6.18.4 , ≤ 6.18.* (semver)
Unaffected: 6.19 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "include/net/dsa.h",
            "net/dsa/dsa.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "ec2b34acb1894cfc10ed22d8277ca4f11e9f4b23",
              "status": "affected",
              "version": "83c0afaec7b730b16c518aecc8e6246ec91b265e",
              "versionType": "git"
            },
            {
              "lessThan": "b358fc6ff3b35a29f7f677da1c67af67d0d560cb",
              "status": "affected",
              "version": "83c0afaec7b730b16c518aecc8e6246ec91b265e",
              "versionType": "git"
            },
            {
              "lessThan": "0e766b77ba5093583dfe609fae0aa1545c46dbbd",
              "status": "affected",
              "version": "83c0afaec7b730b16c518aecc8e6246ec91b265e",
              "versionType": "git"
            },
            {
              "lessThan": "06e219f6a706c367c93051f408ac61417643d2f9",
              "status": "affected",
              "version": "83c0afaec7b730b16c518aecc8e6246ec91b265e",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "include/net/dsa.h",
            "net/dsa/dsa.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.8"
            },
            {
              "lessThan": "4.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.130",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.78",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.19",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.130",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.78",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.4",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn\u0027t make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n   the elevated refcount on the conduit\u0027s kobject. Nominally, the OF and\n   non-OF paths should result in objects having identical reference\n   counts taken, and it is already suspicious that\n   dsa_dev_to_net_device() has a put_device() call which is missing in\n   dsa_port_parse_of(), but we can actually even verify that an issue\n   exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n   \"before\" and \"after\" applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 \u003e /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: \u0027eno2\u0027 (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: \u0027109\u0027 (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n   it can get unregistered at any time, and DSA remains with a long-lived,\n   but in this case stale, cpu_dp-\u003econduit pointer. Holding the net\n   device\u0027s underlying kobject isn\u0027t actually of much help, it just\n   prevents it from being freed (but we never need that kobject\n   directly). What helps us to prevent the net device from being\n   unregistered is the parallel netdev reference mechanism (dev_hold()\n   and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn\u0027t know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n   ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not\n   make user port errors fatal\"), and the cpu_dp-\u003econduit pointers\n   remain valid.  I haven\u0027t audited all call paths to see whether they\n   will actually use the conduit in lack of any user port, but if they\n   do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n   associated to, and we can get into a situation where we\u0027ve moved all\n   user ports away from a conduit, thus no longer hold any reference to\n   it via the net device tracker. But we shouldn\u0027t let it go nonetheless\n   - see the next change in relation to dsa_tree_find_first_conduit()\n   and LAG conduits which disappear.\n   We have to be prepared to return to the physical conduit, so the CPU\n   port must explicitly keep another reference to it. This is also to\n   say: the user ports and their CPU ports may not always keep a\n   reference to the same conduit net device, and both are needed.\n\nAs for the conduit\u0027s kobject for the /sys/class/net/ entry, we don\u0027t\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I\u0027ll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T21:55:58.010Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/ec2b34acb1894cfc10ed22d8277ca4f11e9f4b23"
        },
        {
          "url": "https://git.kernel.org/stable/c/b358fc6ff3b35a29f7f677da1c67af67d0d560cb"
        },
        {
          "url": "https://git.kernel.org/stable/c/0e766b77ba5093583dfe609fae0aa1545c46dbbd"
        },
        {
          "url": "https://git.kernel.org/stable/c/06e219f6a706c367c93051f408ac61417643d2f9"
        }
      ],
      "title": "net: dsa: properly keep track of conduit reference",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-71152",
    "datePublished": "2026-01-23T14:25:52.022Z",
    "dateReserved": "2026-01-13T15:30:19.662Z",
    "dateUpdated": "2026-05-11T21:55:58.010Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2025-71152",
      "date": "2026-07-22",
      "epss": "0.0012",
      "percentile": "0.02167"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-71152\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-01-23T15:16:06.050\",\"lastModified\":\"2026-06-17T10:03:46.087\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnet: dsa: properly keep track of conduit reference\\n\\nProblem description\\n-------------------\\n\\nDSA has a mumbo-jumbo of reference handling of the conduit net device\\nand its kobject which, sadly, is just wrong and doesn\u0027t make sense.\\n\\nThere are two distinct problems.\\n\\n1. The OF path, which uses of_find_net_device_by_node(), never releases\\n   the elevated refcount on the conduit\u0027s kobject. Nominally, the OF and\\n   non-OF paths should result in objects having identical reference\\n   counts taken, and it is already suspicious that\\n   dsa_dev_to_net_device() has a put_device() call which is missing in\\n   dsa_port_parse_of(), but we can actually even verify that an issue\\n   exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\\n   \\\"before\\\" and \\\"after\\\" applying this patch:\\n\\n(unbind the conduit driver for net device eno2)\\necho 0000:00:00.2 \u003e /sys/bus/pci/drivers/fsl_enetc/unbind\\n\\nwe see these lines in the output diff which appear only with the patch\\napplied:\\n\\nkobject: \u0027eno2\u0027 (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\\nkobject: \u0027109\u0027 (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\\n\\n2. After we find the conduit interface one way (OF) or another (non-OF),\\n   it can get unregistered at any time, and DSA remains with a long-lived,\\n   but in this case stale, cpu_dp-\u003econduit pointer. Holding the net\\n   device\u0027s underlying kobject isn\u0027t actually of much help, it just\\n   prevents it from being freed (but we never need that kobject\\n   directly). What helps us to prevent the net device from being\\n   unregistered is the parallel netdev reference mechanism (dev_hold()\\n   and dev_put()).\\n\\nActually we actually use that netdev tracker mechanism implicitly on\\nuser ports since commit 2f1e8ea726e9 (\\\"net: dsa: link interfaces with\\nthe DSA master to get rid of lockdep warnings\\\"), via netdev_upper_dev_link().\\nBut time still passes at DSA switch probe time between the initial\\nof_find_net_device_by_node() code and the user port creation time, time\\nduring which the conduit could unregister itself and DSA wouldn\u0027t know\\nabout it.\\n\\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\\nprevent that from happening, and release the lock only with the netdev\\ntracker having acquired the reference.\\n\\nDo we need to keep the reference until dsa_unregister_switch() /\\ndsa_switch_shutdown()?\\n1: Maybe yes. A switch device will still be registered even if all user\\n   ports failed to probe, see commit 86f8b1c01a0a (\\\"net: dsa: Do not\\n   make user port errors fatal\\\"), and the cpu_dp-\u003econduit pointers\\n   remain valid.  I haven\u0027t audited all call paths to see whether they\\n   will actually use the conduit in lack of any user port, but if they\\n   do, it seems safer to not rely on user ports for that reference.\\n2. Definitely yes. We support changing the conduit which a user port is\\n   associated to, and we can get into a situation where we\u0027ve moved all\\n   user ports away from a conduit, thus no longer hold any reference to\\n   it via the net device tracker. But we shouldn\u0027t let it go nonetheless\\n   - see the next change in relation to dsa_tree_find_first_conduit()\\n   and LAG conduits which disappear.\\n   We have to be prepared to return to the physical conduit, so the CPU\\n   port must explicitly keep another reference to it. This is also to\\n   say: the user ports and their CPU ports may not always keep a\\n   reference to the same conduit net device, and both are needed.\\n\\nAs for the conduit\u0027s kobject for the /sys/class/net/ entry, we don\u0027t\\ncare about it, we can release it as soon as we hold the net device\\nobject itself.\\n\\nHistory and blame attribution\\n-----------------------------\\n\\nThe code has been refactored so many times, it is very difficult to\\nfollow and properly attribute a blame, but I\u0027ll try to make a short\\nhistory which I hope to be correct.\\n\\nWe have two distinct probing paths:\\n- one for OF, introduced in 2016 i\\n---truncated---\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"include/net/dsa.h\",\"net/dsa/dsa.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"83c0afaec7b730b16c518aecc8e6246ec91b265e\",\"lessThan\":\"ec2b34acb1894cfc10ed22d8277ca4f11e9f4b23\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"83c0afaec7b730b16c518aecc8e6246ec91b265e\",\"lessThan\":\"b358fc6ff3b35a29f7f677da1c67af67d0d560cb\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"83c0afaec7b730b16c518aecc8e6246ec91b265e\",\"lessThan\":\"0e766b77ba5093583dfe609fae0aa1545c46dbbd\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"83c0afaec7b730b16c518aecc8e6246ec91b265e\",\"lessThan\":\"06e219f6a706c367c93051f408ac61417643d2f9\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"include/net/dsa.h\",\"net/dsa/dsa.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"4.8\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"4.8\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.130\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.78\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.18.4\",\"lessThanOrEqual\":\"6.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.19\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"4.8\",\"versionEndExcluding\":\"6.18.4\",\"matchCriteriaId\":\"0783A970-2212-4820-B942-2111196CEFF7\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"17B67AA7-40D6-4AFA-8459-F200F3D7CFD1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"C47E4CC9-C826-4FA9-B014-7FE3D9B318B2\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"F71D92C0-C023-48BD-B3B6-70B638EEE298\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/06e219f6a706c367c93051f408ac61417643d2f9\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/0e766b77ba5093583dfe609fae0aa1545c46dbbd\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b358fc6ff3b35a29f7f677da1c67af67d0d560cb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ec2b34acb1894cfc10ed22d8277ca4f11e9f4b23\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}",
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2026-06-28T07:12:50+00:00",
      "cve": "CVE-2025-71152",
      "id": "CVE-2025-71152",
      "initial_release_date": "2025-01-01T00:00:00+00:00",
      "product_status:known_affected": "14",
      "product_status:known_not_affected": "260",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: net: dsa: properly keep track of conduit reference",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-71152.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-07-16T18:09:48Z",
      "cve": "CVE-2025-71152",
      "id": "CVE-2025-71152",
      "initial_release_date": "2026-01-24T00:25:45Z",
      "product_status:known_affected": "318",
      "product_status:known_not_affected": "20",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2025-71152",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2025-71152.json",
      "version": "9"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.