{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2023-53382 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2023-53382 is a critical vulnerability in Linux kernel, published on 18 Sep 2025. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2023-53382 and fix it if it is affected.\n\nWhat it is: CVE-2023-53382 is a critical vulnerability in Linux kernel, published on 18 Sep 2025. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2023-53382 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2023-53382/ (Markdown: https://insights.sbomify.com/CVE-2023-53382/index.md)","id":"CVE-2023-53382","markdown":"https://insights.sbomify.com/CVE-2023-53382/index.md","name":"CVE-2023-53382","record":{"aliases":["BELL-CVE-2023-53382","DEBIAN-CVE-2023-53382","GHSA-5322-f7jr-cv4m","ROOT-OS-UBUNTU-2204-CVE-2023-53382","UBUNTU-CVE-2023-53382"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":true,"product_category":"Linux kernel SMC","requires_auth":"none","summary":"A null pointer dereference in the Linux kernel SMC module causes a crash when SMCRv2 connection attempts fail, leading to denial of service.","user_interaction":"not_required","vuln_class":"null_dereference"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":9.8,"severity":"critical","source":"cna","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-476","name":"NULL Pointer Dereference"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Reset connection when trying to use SMCRv2 fails.\n\nWe found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It\ncan be reproduced by:\n\n- smc_run nginx\n- smc_run wrk -t 32 -c 500 -d 30 http://\u003cip\u003e:\u003cport\u003e\n\n BUG: kernel NULL pointer dereference, address: 0000000000000014\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G        W   E      6.4.0-rc1+ #42\n Workqueue: smc_hs_wq smc_listen_work [smc]\n RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc]\n RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06\n RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000\n RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00\n RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000\n R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180\n R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001\n FS:  0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u003cTASK\u003e\n  ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]\n  ? smcr_buf_map_link+0x24b/0x290 [smc]\n  ? __smc_buf_create+0x4ee/0x9b0 [smc]\n  smc_clc_send_accept+0x4c/0xb0 [smc]\n  smc_listen_work+0x346/0x650 [smc]\n  ? __schedule+0x279/0x820\n  process_one_work+0x1e5/0x3f0\n  worker_thread+0x4d/0x2f0\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0xe5/0x120\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x2c/0x50\n  \u003c/TASK\u003e\n\nDuring the CLC handshake, server sequentially tries available SMCRv2\nand SMCRv1 devices in smc_listen_work().\n\nIf an SMCRv2 device is found. SMCv2 based link group and link will be\nassigned to the connection. Then assumed that some buffer assignment\nerrors happen later in the CLC handshake, such as RMB registration\nfailure, server will give up SMCRv2 and try SMCRv1 device instead. But\nthe resources assigned to the connection won't be reset.\n\nWhen server tries SMCRv1 device, the connection creation process will\nbe executed again. Since conn-\u003elnk has been assigned when trying SMCRv2,\nit will not be set to the correct SMCRv1 link in\nsmcr_lgr_conn_assign_link(). So in such situation, conn-\u003elgr points to\ncorrect SMCRv1 link group but conn-\u003elnk points to the SMCRv2 link\nmistakenly.\n\nThen in smc_clc_send_confirm_accept(), conn-\u003ermb_desc-\u003emr[link-\u003elink_idx]\nwill be accessed. Since the link-\u003elink_idx is not correct, the related\nMR may not have been initialized, so crash happens.\n\n | Try SMCRv2 device first\n |     |-\u003e conn-\u003elgr:\tassign existed SMCRv2 link group;\n |     |-\u003e conn-\u003elink:\tassign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);\n |     |-\u003e sndbuf \u0026 RMB creation fails, quit;\n |\n | Try SMCRv1 device then\n |     |-\u003e conn-\u003elgr:\tcreate SMCRv1 link group and assign;\n |     |-\u003e conn-\u003elink:\tkeep SMCRv2 link mistakenly;\n |     |-\u003e sndbuf \u0026 RMB creation succeed, only RMB-\u003emr[link_idx = 0]\n |         initialized.\n |\n | Then smc_clc_send_confirm_accept() accesses\n | conn-\u003ermb_desc-\u003emr[conn-\u003elink-\u003elink_idx, which is 1], then crash.\n v\n\nThis patch tries to fix this by cleaning conn-\u003elnk before assigning\nlink. In addition, it is better to reset the connection and clean the\nresources assigned if trying SMCRv2 failed in buffer creation or\nregistration.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"net/smc: Reset connection when trying to use SMCRv2 fails.","id":"CVE-2023-53382","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"null_dereference","year":"2023"},"n_packages":0,"n_references":3,"next":{"headline":"irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4","id":"CVE-2023-53383"},"packages":[],"prev":{"headline":"NFSD: fix leaked reference count of nfsd4_ssc_umount_item","id":"CVE-2023-53381"},"products":["Linux"],"published":"2025-09-18","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A null pointer dereference in the Linux kernel SMC module causes a crash when SMCRv2 connection attempts fail, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2023-53382/"}