CVE-2023-53022 (GCVE-0-2023-53022)
Vulnerability from cvelistv5
Published
2025-03-27 16:43
Modified
2025-05-04 07:47
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid deadlock in enetc_tx_onestep_tstamp() This lockdep splat says it better than I could: ================================ WARNING: inconsistent lock state 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0 {IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64 irq event stamp: 7825 hardirqs last enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130 hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8 softirqs last enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8 softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); <Interrupt> lock(_xmit_ETHER#2); *** DEADLOCK *** 3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34 Workqueue: events enetc_tx_onestep_tstamp Call trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11c but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in process context, therefore with softirqs enabled (i.o.w., it can be interrupted by a softirq). If we hold the netif_tx_lock() when there is an interrupt, and the NET_TX softirq then gets scheduled, this will take the netif_tx_lock() a second time and deadlock the kernel. To solve this, use netif_tx_lock_bh(), which blocks softirqs from running.
Impacted products
Vendor Product Version
Linux Linux Version: 7294380c5211687aa4d66166984b152ee84caf5f
Version: 7294380c5211687aa4d66166984b152ee84caf5f
Version: 7294380c5211687aa4d66166984b152ee84caf5f
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/freescale/enetc/enetc.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "8232e5a84d25a84a5cbda0f241a00793fb6eb608",
              "status": "affected",
              "version": "7294380c5211687aa4d66166984b152ee84caf5f",
              "versionType": "git"
            },
            {
              "lessThan": "e893dced1a18e77b1262f5c10169413f0ece0da7",
              "status": "affected",
              "version": "7294380c5211687aa4d66166984b152ee84caf5f",
              "versionType": "git"
            },
            {
              "lessThan": "3c463721a73bdb57a913e0d3124677a3758886fc",
              "status": "affected",
              "version": "7294380c5211687aa4d66166984b152ee84caf5f",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/net/ethernet/freescale/enetc/enetc.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.13"
            },
            {
              "lessThan": "5.13",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.91",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.91",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.9",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.2",
                  "versionStartIncluding": "5.13",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: avoid deadlock in enetc_tx_onestep_tstamp()\n\nThis lockdep splat says it better than I could:\n\n================================\nWARNING: inconsistent lock state\n6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted\n--------------------------------\ninconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-W} usage.\nkworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:\nffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0\n{IN-SOFTIRQ-W} state was registered at:\n  _raw_spin_lock+0x5c/0xc0\n  sch_direct_xmit+0x148/0x37c\n  __dev_queue_xmit+0x528/0x111c\n  ip6_finish_output2+0x5ec/0xb7c\n  ip6_finish_output+0x240/0x3f0\n  ip6_output+0x78/0x360\n  ndisc_send_skb+0x33c/0x85c\n  ndisc_send_rs+0x54/0x12c\n  addrconf_rs_timer+0x154/0x260\n  call_timer_fn+0xb8/0x3a0\n  __run_timers.part.0+0x214/0x26c\n  run_timer_softirq+0x3c/0x74\n  __do_softirq+0x14c/0x5d8\n  ____do_softirq+0x10/0x20\n  call_on_irq_stack+0x2c/0x5c\n  do_softirq_own_stack+0x1c/0x30\n  __irq_exit_rcu+0x168/0x1a0\n  irq_exit_rcu+0x10/0x40\n  el1_interrupt+0x38/0x64\nirq event stamp: 7825\nhardirqs last  enabled at (7825): [\u003cffffdf1f7200cae4\u003e] exit_to_kernel_mode+0x34/0x130\nhardirqs last disabled at (7823): [\u003cffffdf1f708105f0\u003e] __do_softirq+0x550/0x5d8\nsoftirqs last  enabled at (7824): [\u003cffffdf1f7081050c\u003e] __do_softirq+0x46c/0x5d8\nsoftirqs last disabled at (7811): [\u003cffffdf1f708166e0\u003e] ____do_softirq+0x10/0x20\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n       CPU0\n       ----\n  lock(_xmit_ETHER#2);\n  \u003cInterrupt\u003e\n    lock(_xmit_ETHER#2);\n\n *** DEADLOCK ***\n\n3 locks held by kworker/1:3/179:\n #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #1: ffff80000a0bbdc8 ((work_completion)(\u0026priv-\u003etx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #2: ffff3ec4036cd438 (\u0026dev-\u003etx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34\n\nWorkqueue: events enetc_tx_onestep_tstamp\nCall trace:\n print_usage_bug.part.0+0x208/0x22c\n mark_lock+0x7f0/0x8b0\n __lock_acquire+0x7c4/0x1ce0\n lock_acquire.part.0+0xe0/0x220\n lock_acquire+0x68/0x84\n _raw_spin_lock+0x5c/0xc0\n netif_freeze_queues+0x5c/0xc0\n netif_tx_lock+0x24/0x34\n enetc_tx_onestep_tstamp+0x20/0x100\n process_one_work+0x28c/0x6c0\n worker_thread+0x74/0x450\n kthread+0x118/0x11c\n\nbut I\u0027ll say it anyway: the enetc_tx_onestep_tstamp() work item runs in\nprocess context, therefore with softirqs enabled (i.o.w., it can be\ninterrupted by a softirq). If we hold the netif_tx_lock() when there is\nan interrupt, and the NET_TX softirq then gets scheduled, this will take\nthe netif_tx_lock() a second time and deadlock the kernel.\n\nTo solve this, use netif_tx_lock_bh(), which blocks softirqs from\nrunning."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-04T07:47:52.526Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/8232e5a84d25a84a5cbda0f241a00793fb6eb608"
        },
        {
          "url": "https://git.kernel.org/stable/c/e893dced1a18e77b1262f5c10169413f0ece0da7"
        },
        {
          "url": "https://git.kernel.org/stable/c/3c463721a73bdb57a913e0d3124677a3758886fc"
        }
      ],
      "title": "net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-53022",
    "datePublished": "2025-03-27T16:43:48.513Z",
    "dateReserved": "2025-03-27T16:40:15.752Z",
    "dateUpdated": "2025-05-04T07:47:52.526Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2023-53022\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-03-27T17:15:51.710\",\"lastModified\":\"2025-04-15T19:41:54.910\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nnet: enetc: avoid deadlock in enetc_tx_onestep_tstamp()\\n\\nThis lockdep splat says it better than I could:\\n\\n================================\\nWARNING: inconsistent lock state\\n6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted\\n--------------------------------\\ninconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-W} usage.\\nkworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:\\nffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0\\n{IN-SOFTIRQ-W} state was registered at:\\n  _raw_spin_lock+0x5c/0xc0\\n  sch_direct_xmit+0x148/0x37c\\n  __dev_queue_xmit+0x528/0x111c\\n  ip6_finish_output2+0x5ec/0xb7c\\n  ip6_finish_output+0x240/0x3f0\\n  ip6_output+0x78/0x360\\n  ndisc_send_skb+0x33c/0x85c\\n  ndisc_send_rs+0x54/0x12c\\n  addrconf_rs_timer+0x154/0x260\\n  call_timer_fn+0xb8/0x3a0\\n  __run_timers.part.0+0x214/0x26c\\n  run_timer_softirq+0x3c/0x74\\n  __do_softirq+0x14c/0x5d8\\n  ____do_softirq+0x10/0x20\\n  call_on_irq_stack+0x2c/0x5c\\n  do_softirq_own_stack+0x1c/0x30\\n  __irq_exit_rcu+0x168/0x1a0\\n  irq_exit_rcu+0x10/0x40\\n  el1_interrupt+0x38/0x64\\nirq event stamp: 7825\\nhardirqs last  enabled at (7825): [\u003cffffdf1f7200cae4\u003e] exit_to_kernel_mode+0x34/0x130\\nhardirqs last disabled at (7823): [\u003cffffdf1f708105f0\u003e] __do_softirq+0x550/0x5d8\\nsoftirqs last  enabled at (7824): [\u003cffffdf1f7081050c\u003e] __do_softirq+0x46c/0x5d8\\nsoftirqs last disabled at (7811): [\u003cffffdf1f708166e0\u003e] ____do_softirq+0x10/0x20\\n\\nother info that might help us debug this:\\n Possible unsafe locking scenario:\\n\\n       CPU0\\n       ----\\n  lock(_xmit_ETHER#2);\\n  \u003cInterrupt\u003e\\n    lock(_xmit_ETHER#2);\\n\\n *** DEADLOCK ***\\n\\n3 locks held by kworker/1:3/179:\\n #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\\n #1: ffff80000a0bbdc8 ((work_completion)(\u0026priv-\u003etx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\\n #2: ffff3ec4036cd438 (\u0026dev-\u003etx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34\\n\\nWorkqueue: events enetc_tx_onestep_tstamp\\nCall trace:\\n print_usage_bug.part.0+0x208/0x22c\\n mark_lock+0x7f0/0x8b0\\n __lock_acquire+0x7c4/0x1ce0\\n lock_acquire.part.0+0xe0/0x220\\n lock_acquire+0x68/0x84\\n _raw_spin_lock+0x5c/0xc0\\n netif_freeze_queues+0x5c/0xc0\\n netif_tx_lock+0x24/0x34\\n enetc_tx_onestep_tstamp+0x20/0x100\\n process_one_work+0x28c/0x6c0\\n worker_thread+0x74/0x450\\n kthread+0x118/0x11c\\n\\nbut I\u0027ll say it anyway: the enetc_tx_onestep_tstamp() work item runs in\\nprocess context, therefore with softirqs enabled (i.o.w., it can be\\ninterrupted by a softirq). If we hold the netif_tx_lock() when there is\\nan interrupt, and the NET_TX softirq then gets scheduled, this will take\\nthe netif_tx_lock() a second time and deadlock the kernel.\\n\\nTo solve this, use netif_tx_lock_bh(), which blocks softirqs from\\nrunning.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: enetc: evitar bloqueo en enetc_tx_onestep_tstamp() Este splat de lockdep lo dice mejor de lo que yo podr\u00eda: ================================ ADVERTENCIA: estado de bloqueo inconsistente 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 No contaminado -------------------------------- uso inconsistente de {IN-SOFTIRQ-W} -\u0026gt; {SOFTIRQ-ON-W}. kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] toma: ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, en: netif_freeze_queues+0x5c/0xc0 {IN-SOFTIRQ-W} estado se registr\u00f3 en: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64 marca de evento de irq: 7825 hardirqs habilitados por \u00faltima vez en (7825): [] exit_to_kernel_mode+0x34/0x130 hardirqs deshabilitados por \u00faltima vez en (7823): [] __do_softirq+0x550/0x5d8 softirqs habilitados por \u00faltima vez en (7824): [] __do_softirq+0x46c/0x5d8 softirqs deshabilitados por \u00faltima vez en (7811): [] ____do_softirq+0x10/0x20 otra informaci\u00f3n que podr\u00eda ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(_xmit_ETHER#2);  lock(_xmit_ETHER#2); *** BLOQUEO INTERMEDIO *** 3 bloqueos mantenidos por kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)eventos){+.+.}-{0:0}, en: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(\u0026amp;priv-\u0026gt;tx_onestep_tstamp)){+.+.}-{0:0}, en: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (\u0026amp;dev-\u0026gt;tx_global_lock){+.+.}-{3:3}, en: netif_tx_lock+0x1c/0x34 Cola de trabajo: eventos enetc_tx_onestep_tstamp Rastreo de llamadas: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0worker_thread+0x74/0x450 kthread+0x118/0x11c pero lo dir\u00e9 de todos modos: el elemento de trabajo enetc_tx_onestep_tstamp() se ejecuta en el contexto del proceso, por lo tanto, con softirqs habilitado (Es decir, puede ser interrumpido por un softirq). Si mantenemos la ejecuci\u00f3n de netif_tx_lock() cuando hay una interrupci\u00f3n, y luego se programa el softirq NET_TX, se ejecutar\u00e1 netif_tx_lock() por segunda vez y se bloquear\u00e1 el kernel. Para solucionar esto, use netif_tx_lock_bh(), que impide la ejecuci\u00f3n de los softirq.\"}],\"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:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-667\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.13\",\"versionEndExcluding\":\"5.15.91\",\"matchCriteriaId\":\"450804D3-1879-4858-A68D-9C0BCBF13142\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.9\",\"matchCriteriaId\":\"ED5B6045-B1D2-4E03-B194-9005A351BCAE\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"FF501633-2F44-4913-A8EE-B021929F49F6\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"2BDA597B-CAC1-4DF0-86F0-42E142C654E9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"725C78C9-12CE-406F-ABE8-0813A01D66E8\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"A127C155-689C-4F67-B146-44A57F4BFD85\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/3c463721a73bdb57a913e0d3124677a3758886fc\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/8232e5a84d25a84a5cbda0f241a00793fb6eb608\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/e893dced1a18e77b1262f5c10169413f0ece0da7\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…