Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG}, }; static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG}, }; Therefore, the current code is buggy and this nla_parse_nested_deprecated could overflow the dcbnl_pfc_up
NLA_FLAG}, }; Therefore, the current code is buggy and this nla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use the adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0. Hence use the correct policy dcbnl_bcn_nest to parse the nested tb[DCB_ATTR_BCN] TLV. References: - https://git.kernel.org/stable/c/5b3dbedb8d4a0f9f7ce904d76b885438af2a21f9 - https://git.kernel.org/stable/c/8e309f43d0ca4051d20736c06a6f84bbddd881da - https://git.kernel.org/stable/c/a0da2684db18dead3bcee12fb185e596e3d63c2b - https://git.kernel.org/stable/c/ecff20e193207b44fdbfe64d7de89890f0a7fe6c - https://git.kernel.org/stable/c/199fde04bd875d28b3a5ca525eaaa004eec6e947 - https://git.kernel.or
fe64d7de89890f0a7fe6c - https://git.kernel.org/stable/c/199fde04bd875d28b3a5ca525eaaa004eec6e947 - https://git.kernel.org/stable/c/31d49ba033095f6e8158c60f69714a500922e0c3
CVE ID: CVE-2023-53370 State: PUBLISHED Published: 2025-09-18T13:33:18.117Z Last Updated: 2025-09-19T15:21:38.831Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix memory leak in mes self test The fences associated with mes queue have to be freed up during amdgpu_ring_fini. References: - https://git.kernel.org/stable/c/ce3288d8d654b252ba832626e7de481c195ef20a - https://git.kernel.org/stable/c/8d8c96efcec95736622381b2afc0fe9e317f88aa - https://git.kernel.org/stable/c/31d7c3a4fc3d312a0646990767647925d5bde540
CVE ID: CVE-2023-53371 State: PUBLISHED Published: 2025-09-18T13:33:18.838Z Last Updated: 2025-09-18T13:33:18.838Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create The memory pointed to by the fs->any pointer is not freed in the error path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak. Fix by freeing the memory in the error path, thereby making the error path identical to mlx5e_fs_tt_redirect_any_destroy(). References: - https://git.kernel.org/stable/c/75df2fe6d160e16be880aacacd521b135d7177c9 - https://git.kernel.org/stable/c/8a75a6f169c3df3a94802
git.kernel.org/stable/c/75df2fe6d160e16be880aacacd521b135d7177c9 - https://git.kernel.org/stable/c/8a75a6f169c3df3a94802314aa61282772ac75b8 - https://git.kernel.org/stable/c/3250affdc658557a41df9c5fb567723e421f8bf2
CVE ID: CVE-2023-53372 State: PUBLISHED Published: 2025-09-18T13:33:19.549Z Last Updated: 2025-09-18T13:33:19.549Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sctp: fix a potential overflow in sctp_ifwdtsn_skip Currently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it only checks the pos against the end of the chunk. However, the data left for the last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereference it as struct sctp_ifwdtsn_skip may cause coverflow. This patch fixes it by checking the pos against "the end of the chunk - sizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar to sctp_fwdtsn_
the pos against "the end of the chunk - sizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar to sctp_fwdtsn_skip. References: - https://git.kernel.org/stable/c/4fbd094d4131a10d06a45d64158567052a35b3f4 - https://git.kernel.org/stable/c/ad831a7079c99c01e801764b53bc9997c2e9c0f7 - https://git.kernel.org/stable/c/79b28f42214a3d0d6a8c514db3602260bd5d6cb5 - https://git.kernel.org/stable/c/6109f5b13ce3e3e537db6f18976ec0e9118d1c6f - https://git.kernel.org/stable/c/5c9367ac5a22d71841bcd00130f9146c9b227d57 - https://git.kernel.org/stable/c/ad988e9b5ff04607e624a459209e8c2d0c15fc73 - https://git.kernel.org/stable/c/32832a2caf82663870126c5186cf8f86c8b2a649
CVE ID: CVE-2023-53373 State: PUBLISHED Published: 2025-09-18T13:33:20.264Z Last Updated: 2025-09-18T13:33:20.264Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: seqiv - Handle EBUSY correctly As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free. References: - https://git.kernel.org/stable/c/cc4d0d4251748a8a68026938f4055d2ac47c5719 - https://git.kernel.or
ter-free. References: - https://git.kernel.org/stable/c/cc4d0d4251748a8a68026938f4055d2ac47c5719 - https://git.kernel.org/stable/c/1effbddaff60eeef8017c6dea1ee0ed970164d14 - https://git.kernel.org/stable/c/63551e4b7cbcd9914258827699eb2cb6ed6e4a16 - https://git.kernel.org/stable/c/ae849d2f48019ff9c104e32bf588ccbfb200e971 - https://git.kernel.org/stable/c/36ec108b7bd7e280edb22de028467bd09d644620 - https://git.kernel.org/stable/c/4d497e8b200a175094e0ac252ed878add39b8771 - https://git.kernel.org/stable/c/9477db935eb690f697d9bcc4f608927841bc8b36 - https://git.kernel.org/stable/c/32e62025e5e52fbe4812ef044759de7010b15dbc
CVE ID: CVE-2023-53374 State: PUBLISHED Published: 2025-09-18T13:33:20.965Z Last Updated: 2025-09-18T13:33:20.965Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early Not calling hci_(dis)connect_cfm before deleting conn referred to by a socket generally results to use-after-free. When cleaning up SCO connections when the parent ACL is deleted too early, use hci_conn_failed to do the connection cleanup properly. We also need to clean up ISO connections in a similar situation when connecting has started but LE Create CIS is not yet sent, so do it too here. Refere
nections in a similar situation when connecting has started but LE Create CIS is not yet sent, so do it too here. References: - https://git.kernel.org/stable/c/397d58007532644b35fad746da48c41161f32a57 - https://git.kernel.org/stable/c/e94b898463a62b72a2a8b75dea8936bf4db78e00 - https://git.kernel.org/stable/c/3344d318337d9dca928fd448e966557ec5063f85
CVE ID: CVE-2023-53375 State: PUBLISHED Published: 2025-09-18T13:33:21.664Z Last Updated: 2025-09-18T13:33:21.664Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Free error logs of tracing instances When a tracing instance is removed, the error messages that hold errors that occurred in the instance needs to be freed. The following reports a memory leak: # cd /sys/kernel/tracing # mkdir instances/foo # echo 'hist:keys=x' > instances/foo/events/sched/sched_switch/trigger # cat instances/foo/error_log [ 117.404795] hist:sched:sched_switch: error: Couldn't find field Command: hist:keys=x ^ # rmdir instances/foo Then check
117.404795] hist:sched:sched_switch: error: Couldn't find field Command: hist:keys=x ^ # rmdir instances/foo Then check for memory leaks: # echo scan > /sys/kernel/debug/kmemleak # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff88810d8ec700 (size 192): comm "bash", pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha....`.ha.... a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0......&....... backtrace: [<00000000dae26536>] kmalloc_trace+0x2a/0xa0 [<00000000b2938940>] tracing_log_err+0x277/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_his
0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc unreferenced object 0xffff888170c35a00 (size 32): comm "bash", pid 869, jiffies 4294950577 (age 215.752s) hex dump (first 32 bytes): 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=
: 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x......... backtrace: [<000000006a747de5>] __kmalloc+0x4d/0x160 [<000000000039df5f>] tracing_log_err+0x29b/0x2e0 [<000000004a0e1b07>] parse_atom+0x966/0xb40 [<0000000023b24337>] parse_expr+0x5f3/0xdb0 [<00000000594ad074>] event_hist_trigger_parse+0x27f8/0x3560 [<00000000293a9645>] trigger_process_regex+0x135/0x1a0 [<000000005c22b4f2>] event_trigger_write+0x87/0xf0 [<000000002cadc509>] vfs_write+0x162/0x670 [<0000000059c3b9be>] ksys_write+0xca/0x170 [<00000000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc The problem is that
000f1cddc00>] do_syscall_64+0x3e/0xc0 [<00000000868ac68c>] entry_SYSCALL_64_after_hwframe+0x72/0xdc The problem is that the error log needs to be freed when the instance is removed. References: - https://git.kernel.org/stable/c/987f599fc556a4e64c405d8dde32c70311e8c278 - https://git.kernel.org/stable/c/6e36373aa5ffa8e00fe7c71b3209f6f17081e552 - https://git.kernel.org/stable/c/33d5d4e67a0e13c3ca6257fa67bf6503bc000878 - https://git.kernel.org/stable/c/c0cf0f55be043ef67c38f492aa37ed1986d2f6b6 - https://git.kernel.org/stable/c/46771c34d6721abfd9e7903eaed2201051eebec6 - https://git.kernel.org/stable/c/3357c6e429643231e60447b52ffbb7ac895aca22
CVE ID: CVE-2023-53376 State: PUBLISHED Published: 2025-09-18T13:33:22.364Z Last Updated: 2025-09-18T13:33:22.364Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Use number of bits to manage bitmap sizes To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using byte as unit. However, bitmap helper functions assume that bitmaps are allocated using unsigned long as unit. This gap causes memory access beyond the bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG was observed at firmware download to eHBA-9600. Call trace indicated that the out-of-bounds access happened in find_first_z
observed at firmware download to eHBA-9600. Call trace indicated that the out-of-bounds access happened in find_first_zero_bit() called from mpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap. To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use number of bits, and call bitmap helper functions which take number of bits as arguments. For memory allocation, call bitmap_zalloc() instead of kzalloc() and krealloc(). For memory free, call bitmap_free() instead of kfree(). For zero clear, call bitmap_clear() instead of memset(). Remove three fields for bitmap byte sizes in struct scmd_priv which are no longer required. Replace the field dev_handle_bitmap_sz with dev_handle_bit
byte sizes in struct scmd_priv which are no longer required. Replace the field dev_handle_bitmap_sz with dev_handle_bitmap_bits to keep number of bits of removepend_bitmap across resize. References: - https://git.kernel.org/stable/c/6a675a6d57d31da43d8da576465c1cd5d5b0bd3d - https://git.kernel.org/stable/c/8ac713d2e9845e9234bb12ae5903040685d5aff9 - https://git.kernel.org/stable/c/339e61565f81a6534afdc18fd854b2e2628bf5db
CVE ID: CVE-2023-53377 State: PUBLISHED Published: 2025-09-18T13:33:23.162Z Last Updated: 2025-09-18T13:33:23.162Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: prevent use-after-free by freeing the cfile later In smb2_compound_op we have a possible use-after-free which can cause hard to debug problems later on. This was revealed during stress testing with KASAN enabled kernel. Fixing it by moving the cfile free call to a few lines below, after the usage. References: - https://git.kernel.org/stable/c/4fe07d55a5461e66a55fbefb57f85ff0facea32b - https://git.kernel.org/stable/c/b6353518ef8180816e863aa23b06456f395404d6 - http
e07d55a5461e66a55fbefb57f85ff0facea32b - https://git.kernel.org/stable/c/b6353518ef8180816e863aa23b06456f395404d6 - https://git.kernel.org/stable/c/d017880782cf71f8820ee4a2002843893176501d - https://git.kernel.org/stable/c/33f736187d08f6bc822117629f263b97d3df4165
CVE ID: CVE-2023-53378 State: PUBLISHED Published: 2025-09-18T13:33:23.905Z Last Updated: 2025-09-18T13:33:23.905Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Treat the DPT BO as a framebuffer Currently i915_gem_object_is_framebuffer() doesn't treat the BO containing the framebuffer's DPT as a framebuffer itself. This means eg. that the shrinker can evict the DPT BO while leaving the actual FB BO bound, when the DPT is allocated from regular shmem. That causes an immediate oops during hibernate as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for t
e as we try to rewrite the PTEs inside the already evicted DPT obj. TODO: presumably this might also be the reason for the DPT related display faults under heavy memory pressure, but I'm still not sure how that would happen as the object should be pinned by intel_dpt_pin() while in active use by the display engine... (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a) References: - https://git.kernel.org/stable/c/c781c107731fc09ce4330c8c636b8446d0f72aa4 - https://git.kernel.org/stable/c/5390a02b4508416b9bee96674f141c68f89bafbc - https://git.kernel.org/stable/c/3413881e1ecc3cba722a2e87ec099692eed5be28
CVE ID: CVE-2023-53379 State: PUBLISHED Published: 2025-09-18T13:33:24.625Z Last Updated: 2025-09-18T13:33:24.625Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe() Smatch reports: drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe() warn: missing unwind goto? After geting irq, if ret < 0, it will return without error handling to free memory. Just add error handling to fix this problem. References: - https://git.kernel.org/stable/c/3e5a7bebf832b1482efe27bcc15a88c5b28a30d0 - https://git.kernel.org/stable/c/4da9edeccf77d7b4c6dbcb34d5908acdaa5bd7e3 - https://git.kernel.org/stable/c/
c5b28a30d0 - https://git.kernel.org/stable/c/4da9edeccf77d7b4c6dbcb34d5908acdaa5bd7e3 - https://git.kernel.org/stable/c/fe9cdc19861950582f077f254a12026e169eaee5 - https://git.kernel.org/stable/c/56901de563359de20513e16a9ae008ae2c22e9a9 - https://git.kernel.org/stable/c/ecf26d6e1b5450620c214feea537bb6ce05c6741 - https://git.kernel.org/stable/c/dd9b7c89a80428cc5f4ae0d2e1311fdedb2a1aac - https://git.kernel.org/stable/c/38dbd6f72bfbeba009efe0e9ec1f3ff09f9e23fa - https://git.kernel.org/stable/c/342161c11403ea00e9febc16baab1d883d589d04
CVE ID: CVE-2023-53380 State: PUBLISHED Published: 2025-09-18T13:33:25.383Z Last Updated: 2025-09-18T13:33:25.383Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request There are two check of 'mreplace' in raid10_sync_request(). In the first check, 'need_replace' will be set and 'mreplace' will be used later if no-Faulty 'mreplace' exists, In the second check, 'mreplace' will be set to NULL if it is Faulty, but 'need_replace' will not be changed accordingly. null-ptr-deref occurs if Faulty is set between two check. Fix it by merging two checks into one. And replace 'need
ngly. null-ptr-deref occurs if Faulty is set between two check. Fix it by merging two checks into one. And replace 'need_replace' with 'mreplace' because their values are always the same. References: - https://git.kernel.org/stable/c/45fa023b3334a7ae6f6c4eb977295804222dfa28 - https://git.kernel.org/stable/c/2990e2ece18dd4cca71b3109c80517ad94adb065 - https://git.kernel.org/stable/c/f4368a462b1f9a8ecc2fdb09a28c3d4cad302a4f - https://git.kernel.org/stable/c/222cc459d59857ee28a5366dc225ab42b22f9272 - https://git.kernel.org/stable/c/b5015b97adda6a24dd3e713c63e521ecbeff25c6 - https://git.kernel.org/stable/c/144c7fd008e0072b0b565f1157eec618de54ca8a - https://git.kernel.org/stable/c/34817a2441747b48
ps://git.kernel.org/stable/c/144c7fd008e0072b0b565f1157eec618de54ca8a - https://git.kernel.org/stable/c/34817a2441747b48e444cb0e05d84e14bc9443da
CVE ID: CVE-2023-53381 State: PUBLISHED Published: 2025-09-18T13:33:26.234Z Last Updated: 2025-09-18T13:33:26.234Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFSD: fix leaked reference count of nfsd4_ssc_umount_item The reference count of nfsd4_ssc_umount_item is not decremented on error conditions. This prevents the laundromat from unmounting the vfsmount of the source file. This patch decrements the reference count of nfsd4_ssc_umount_item on error. References: - https://git.kernel.org/stable/c/2da50149981d05955e51c28e982e9ac29bd73417 - https://git.kernel.org/stable/c/80a15dc4a0214b55ca42675bb0bb2a8d857eb1d0 - https://git
81d05955e51c28e982e9ac29bd73417 - https://git.kernel.org/stable/c/80a15dc4a0214b55ca42675bb0bb2a8d857eb1d0 - https://git.kernel.org/stable/c/9f0df37520a27ad99eaacf38418b3d2bb5023105 - https://git.kernel.org/stable/c/6c3c05402547aaca3edb23327b50f01a881831b9 - https://git.kernel.org/stable/c/34e8f9ec4c9ac235f917747b23a200a5e0ec857b
CVE ID: CVE-2023-53382 State: PUBLISHED Published: 2025-09-18T13:33:27.029Z Last Updated: 2025-09-18T13:33:27.029Z Vendors: Linux Products: Linux Description: 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: 24
resent 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:ffff8f1aef
f8f1846f56180 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
ten_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 conn
1 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; | |->
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
ies 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. References: - https://git.kernel.org/stable/c/9540765d1882d15497d880096de99fafabcfa08c - https://git.kernel.org/stable/c/d33be18917ffe69865dfed18b0a67b0dee0b47d7 - https://git.kernel.org/stable/c/35112271672ae98f45df7875244a4e33aa215e31
CVE ID: CVE-2023-53383 State: PUBLISHED Published: 2025-09-18T13:33:27.731Z Last Updated: 2025-09-18T13:33:27.731Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4 The T241 platform suffers from the T241-FABRIC-4 erratum which causes unexpected behavior in the GIC when multiple transactions are received simultaneously from different sources. This hardware issue impacts NVIDIA server platforms that use more than two T241 chips interconnected. Each chip has support for 320 {E}SPIs. This issue occurs when multiple packets from different GICs are incorrectly interleaved at th
s support for 320 {E}SPIs. This issue occurs when multiple packets from different GICs are incorrectly interleaved at the target chip. The erratum text below specifies exactly what can cause multiple transfer packets susceptible to interleaving and GIC state corruption. GIC state corruption can lead to a range of problems, including kernel panics, and unexpected behavior. >From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer p