{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2023-53022", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-03-27T16:40:15.752Z", "datePublished": "2025-03-27T16:43:48.513Z", "dateUpdated": "2025-03-27T16:43:48.513Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2025-03-27T16:43:48.513Z"}, "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} -> {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): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130\nhardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8\nsoftirqs last enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8\nsoftirqs last disabled at (7811): [<ffffdf1f708166e0>] ____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 <Interrupt>\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)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #2: ffff3ec4036cd438 (&dev->tx_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'll 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."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/net/ethernet/freescale/enetc/enetc.c"], "versions": [{"version": "7294380c5211687aa4d66166984b152ee84caf5f", "lessThan": "8232e5a84d25a84a5cbda0f241a00793fb6eb608", "status": "affected", "versionType": "git"}, {"version": "7294380c5211687aa4d66166984b152ee84caf5f", "lessThan": "e893dced1a18e77b1262f5c10169413f0ece0da7", "status": "affected", "versionType": "git"}, {"version": "7294380c5211687aa4d66166984b152ee84caf5f", "lessThan": "3c463721a73bdb57a913e0d3124677a3758886fc", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/net/ethernet/freescale/enetc/enetc.c"], "versions": [{"version": "5.13", "status": "affected"}, {"version": "0", "lessThan": "5.13", "status": "unaffected", "versionType": "semver"}, {"version": "5.15.91", "lessThanOrEqual": "5.15.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.9", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.2", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "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-5f407fcff5a0"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "450804D3-1879-4858-A68D-9C0BCBF13142", "versionEndExcluding": "5.15.91", "versionStartIncluding": "5.13", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "ED5B6045-B1D2-4E03-B194-9005A351BCAE", "versionEndExcluding": "6.1.9", "versionStartIncluding": "5.16", "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", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "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} -> {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): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130\nhardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8\nsoftirqs last enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8\nsoftirqs last disabled at (7811): [<ffffdf1f708166e0>] ____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 <Interrupt>\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)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n #2: ffff3ec4036cd438 (&dev->tx_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'll 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} -&gt; {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)(&amp;priv-&gt;tx_onestep_tstamp)){+.+.}-{0:0}, en: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&amp;dev-&gt;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."}], "id": "CVE-2023-53022", "lastModified": "2025-04-15T19:41:54.910", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2025-03-27T17:15:51.710", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "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"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-667"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()", "id": "2355501", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2355501"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-833", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nnet: enetc: avoid deadlock in enetc_tx_onestep_tstamp()\nThis lockdep splat says it better than I could:\n================================\nWARNING: inconsistent lock state\n6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted\n--------------------------------\ninconsistent {IN-SOFTIRQ-W} -> {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\nsch_direct_xmit+0x148/0x37c\n__dev_queue_xmit+0x528/0x111c\nip6_finish_output2+0x5ec/0xb7c\nip6_finish_output+0x240/0x3f0\nip6_output+0x78/0x360\nndisc_send_skb+0x33c/0x85c\nndisc_send_rs+0x54/0x12c\naddrconf_rs_timer+0x154/0x260\ncall_timer_fn+0xb8/0x3a0\n__run_timers.part.0+0x214/0x26c\nrun_timer_softirq+0x3c/0x74\n__do_softirq+0x14c/0x5d8\n____do_softirq+0x10/0x20\ncall_on_irq_stack+0x2c/0x5c\ndo_softirq_own_stack+0x1c/0x30\n__irq_exit_rcu+0x168/0x1a0\nirq_exit_rcu+0x10/0x40\nel1_interrupt+0x38/0x64\nirq event stamp: 7825\nhardirqs last enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130\nhardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8\nsoftirqs last enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8\nsoftirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20\nother info that might help us debug this:\nPossible unsafe locking scenario:\nCPU0\n----\nlock(_xmit_ETHER#2);\n<Interrupt>\nlock(_xmit_ETHER#2);\n*** DEADLOCK ***\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)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0\n#2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34\nWorkqueue: events enetc_tx_onestep_tstamp\nCall trace:\nprint_usage_bug.part.0+0x208/0x22c\nmark_lock+0x7f0/0x8b0\n__lock_acquire+0x7c4/0x1ce0\nlock_acquire.part.0+0xe0/0x220\nlock_acquire+0x68/0x84\n_raw_spin_lock+0x5c/0xc0\nnetif_freeze_queues+0x5c/0xc0\nnetif_tx_lock+0x24/0x34\nenetc_tx_onestep_tstamp+0x20/0x100\nprocess_one_work+0x28c/0x6c0\nworker_thread+0x74/0x450\nkthread+0x118/0x11c\nbut I'll 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.\nTo solve this, use netif_tx_lock_bh(), which blocks softirqs from\nrunning."], "name": "CVE-2023-53022", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2025-03-27T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2023-53022\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-53022\nhttps://lore.kernel.org/linux-cve-announce/2025032718-CVE-2023-53022-b539@gregkh/T"], "threat_severity": "Moderate"}