CVE-2023-53382
CriticalCVSS 9.8Exploitation Probability (EPSS)
Low risk19th percentile - higher than 19% of all known CVEs
Summary
A vulnerability in the Linux kernel's SMC (Shared Memory Communications) module was found. When trying to use SMCRv2 and then falling back to SMCRv1, resources assigned to the connection are not reset, leading to a NULL pointer dereference and system crash.
Risk Assessment
An attacker could cause a system crash (kernel panic) by triggering a specific sequence of network operations using SMC, resulting in denial of service.
Recommendation
It is recommended to immediately update the Linux kernel to a version containing the fix (commit that resets the connection when SMCRv2 attempt fails). If updating is not possible, consider disabling SMC functionality or restricting access to services using SMC.
Other vulnerabilities in Linux kernel
See all- CVE-2026-93204Unknown
In the Linux kernel, the batman-adv module's dat handling updated MAC addresses using a simple copy, which could be partially observed by parallel readers. A reader might transport a half-updated MAC address over the network or use it in ARP responses, poisoning the ARP cache. The fix uses atomic64_t to store the 48-bit MAC address, ensuring readers see either the old or new address, never a mixture.
- CVE-2026-93202Unknown
A bug in the Linux kernel's I3C subsystem causes recursive locking during registration of new I3C devices. The function i3c_master_register_new_i3c_devs() registers devices while holding i3c_bus_normaluse_lock(), and device_register() can immediately trigger a probe callback that tries to acquire the same lock again, leading to a deadlock. The fix separates device creation from registration and uses the maintenance lock.
- CVE-2026-93200Unknown
The Linux kernel's i3c master subsystem had a use-after-free vulnerability in the master->this pointer. Sysfs attribute callbacks dereferenced master->this, which was freed in i3c_master_detach_free_devs() before the master device was released. The fix keeps master->this alive until i3c_masterdev_release() and resets it on error paths.
- CVE-2026-93199Unknown
In the Linux kernel, the i3c_master_search_i3c_dev_duplicate() function that searches for duplicate I3C devices can incorrectly match the master device itself (master->this), returning the controller as a duplicate. Since the controller is not a target device, it cannot be a duplicate of one. The fix excludes master->this from matching.
- CVE-2026-93198Unknown
In the Linux kernel, the dm-pcache module does not validate the persisted dirty_tail chain at load. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, causing cache_writeback_fn() to re-arm itself forever. The fix adds validation of the dirty_tail chain at load with a hop cap.
- CVE-2026-93197Unknown
A bug in the Linux kernel's memcg subsystem causes LRU size accounting to be copied to the parent instead of moved when a memory cgroup is offlined, leaving stale counters on the child. This makes the LRU (or MGLRU) scanner read phantom sizes and grind through empty lists on dying cgroups, over-budgeting limits and wasting CPU. On one host, counters described 476 GiB of pages—1.89x the machine's RAM.
- CVE-2026-93195Unknown
In the Linux kernel, the drm/bridge synopsys dw-dp driver initializes and registers the DisplayPort AUX channel during dw_dp_bind(), but never unregisters it. This may lead to resource leaks and/or use-after-free. The fix adds the missing dw_dp_unbind() function to allow cleanup.
- CVE-2026-93194Unknown
In the Linux kernel, the drm/rockchip dw_dp driver initializes and registers core resources such as the DisplayPort AUX channel during dw_dp_bind(), but never unregisters them. This leads to memory leaks and/or use-after-free, as shown in a KASAN report. The issue is fixed by using the exported dw_dp_unbind() function in the component's unbind() callback and in its bind() error path.
- CVE-2026-93193Unknown
In the Linux kernel, the drm/rockchip analogix_dp driver has an OF node reference leak in rockchip_dp_drm_encoder_enable(), because of_get_child_by_name() does not call of_node_put() symmetrically. The fix uses __free(device_node) to automatically manage reference release.
- CVE-2026-93191Unknown
In the Linux kernel, smack_msg_queue_msgrcv() incorrectly checks permissions of the 'current' task instead of the 'target' task. In the pipelined_send() optimization path, the sender checks on behalf of the receiver, so an unauthorized receiver can get the message, violating Smack MAC policy. The fix checks permissions on the 'target' task.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: net/smc: Reset connection when trying to use SMCRv2 fails. We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It can be reproduced by: - smc_run nginx - smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port> BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ? __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ? __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 </TASK> During the CLC handshake, server sequentially tries available SMCRv2 and SMCRv1 devices in smc_listen_work(). If an SMCRv2 device is found. SMCv2 based link group and link will be assigned to the connection. Then assumed that some buffer assignment errors happen later in the CLC handshake, such as RMB registration failure, server will give up SMCRv2 and try SMCRv1 device instead. But the resources assigned to the connection won't be reset. When server tries SMCRv1 device, the connection creation process will be executed again. Since conn->lnk has been assigned when trying SMCRv2, it will not be set to the correct SMCRv1 link in smcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to correct SMCRv1 link group but conn->lnk points to the SMCRv2 link mistakenly. Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx] will be accessed. Since the link->link_idx is not correct, the related MR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr: create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. v This patch tries to fix this by cleaning conn->lnk before assigning link. In addition, it is better to reset the connection and clean the resources assigned if trying SMCRv2 failed in buffer creation or registration.