Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
>] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029 [<ffffffff851b4a82>] packet_snd net/packet/af_packet.c:3111 [inline] [<ffffffff851b4a82>] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142 [<ffffffff84669a12>] sock_sendmsg_nosec net/socket.c:716 [inline] [<ffffffff84669a12>] sock_sendmsg net/socket.c:736 [inline] [<ffffffff84669a12>] __sys_sendto+0x472/0x5f0 net/socket.c:2139 [<ffffffff84669c75>] __do_sys_sendto net/socket.c:2151 [inline] [<ffffffff84669c75>] __se_sys_sendto net/socket.c:2147 [inline] [<ffffffff84669c75>] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147 [<ffffffff8551d40f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff8551d40f>] do_syscall_64+0x
ket.c:2147 [<ffffffff8551d40f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff8551d40f>] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80 [<ffffffff85600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/4188c5269475ac59d467b5814c5df02756f6d907 - https://git.kernel.org/stable/c/34a5ee69ec6273f0aee79e7ce4d14afc83ca8122 - https://git.kernel.org/stable/c/9dd9ffe118415b4ac1cebac43443000072bc8f46 - https://git.kernel.org/stable/c/55caf900e13cd04466def08173a14b41d18c19c3 - https://git.kernel.org/stable/c/15eaeb8941f12fcc2713c4bf6eb8f76a37854b4d - https://git.kernel.org/stable/c/4063384ef762cc5946fc7a3f89879e76c6ec51e2
CVE ID: CVE-2023-53434 State: PUBLISHED Published: 2025-09-18T16:04:13.761Z Last Updated: 2025-10-29T10:50:24.761Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores The IRAM is part of the HiFi DSP. According to hardware specification only 32-bits write are allowed otherwise we get a Kernel panic. Therefore add a custom memory copy and memset functions to deal with the above restriction. References: - https://git.kernel.org/stable/c/44361033a8806aabd0f49b24e5a2fc07232cc5ff - https://git.kernel.org/stable/c/331cd77f3d02c35f98b48d1aa934c54c4e7102c8 -
/c/44361033a8806aabd0f49b24e5a2fc07232cc5ff - https://git.kernel.org/stable/c/331cd77f3d02c35f98b48d1aa934c54c4e7102c8 - https://git.kernel.org/stable/c/408ec1ff0caa340c57eecf4cbd14ef0132036a50
CVE ID: CVE-2023-53435 State: PUBLISHED Published: 2025-09-18T16:04:14.476Z Last Updated: 2025-09-18T16:04:14.476Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cassini: Fix a memory leak in the error handling path of cas_init_one() cas_saturn_firmware_init() allocates some memory using vmalloc(). This memory is freed in the .remove() function but not it the error handling path of the probe. Add the missing vfree() to avoid a memory leak, should an error occur. References: - https://git.kernel.org/stable/c/11c0ed097a874156957b515d0ba7e356142eab87 - https://git.kernel.org/stable/c/60d8e8b88087d68e10c8991a0f6733fa2f963ff0 - http
c0ed097a874156957b515d0ba7e356142eab87 - https://git.kernel.org/stable/c/60d8e8b88087d68e10c8991a0f6733fa2f963ff0 - https://git.kernel.org/stable/c/e20105d967ab5b53ff50a0e5991fe37324d2ba20 - https://git.kernel.org/stable/c/dc61f7582cc92d547d02e141cd66f5d1f4ed8012 - https://git.kernel.org/stable/c/234e744d86bd95b381d24546df2dba72804e0219 - https://git.kernel.org/stable/c/172146c26f0c1b86ab4e9ebffc7e06f04229fa17 - https://git.kernel.org/stable/c/b8b1a667744741fa7807b09a12797a27f14f3fac - https://git.kernel.org/stable/c/412cd77a2c24b191c65ea53025222418db09817c
CVE ID: CVE-2023-53436 State: PUBLISHED Published: 2025-09-18T16:04:15.138Z Last Updated: 2025-09-18T16:04:15.138Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: snic: Fix possible memory leak if device_add() fails If device_add() returns error, the name allocated by dev_set_name() needs be freed. As the comment of device_add() says, put_device() should be used to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanp(). References: - https://git.kernel.org/stable/c/789275f7c0544374d40bc8d9c81f96751a41df45 - https://git.kernel.org/stable/c/f830968d464f55e
tps://git.kernel.org/stable/c/789275f7c0544374d40bc8d9c81f96751a41df45 - https://git.kernel.org/stable/c/f830968d464f55e11bc9260a132fc77daa266aa3 - https://git.kernel.org/stable/c/cea09922f5f75652d55b481ee34011fc7f19868b - https://git.kernel.org/stable/c/58889d5ad74cbc1c9595db74e13522b58b69b0ec - https://git.kernel.org/stable/c/461f8ac666fa232afee5ed6420099913ec4e4ba2 - https://git.kernel.org/stable/c/7723a5d5d187626c4c640842e522cf4e9e39492e - https://git.kernel.org/stable/c/ed0acb1ee2e9322b96611635a9ca9303d15ac76c - https://git.kernel.org/stable/c/41320b18a0e0dfb236dba4edb9be12dba1878156
CVE ID: CVE-2023-53437 State: PUBLISHED Published: 2025-09-18T16:04:15.807Z Last Updated: 2025-09-18T16:04:15.807Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Handle cameras with invalid descriptors If the source entity does not contain any pads, do not create a link. References: - https://git.kernel.org/stable/c/c8f4a424af5879baefb0fb8a8a09b09ea1779483 - https://git.kernel.org/stable/c/2914259fcea23971c6fed8b2618d3a729a78c365 - https://git.kernel.org/stable/c/4e4e6ca62e77539d4df8d13137e2683b10baddd9 - https://git.kernel.org/stable/c/d8aa2e1ae6426d7cbddf1735aed1a63ddf0e6909 - https://git.kernel.org/stable/c/
3b10baddd9 - https://git.kernel.org/stable/c/d8aa2e1ae6426d7cbddf1735aed1a63ddf0e6909 - https://git.kernel.org/stable/c/31a8d11d28b57656cebfbd4c0b8b76f6ad5b017d - https://git.kernel.org/stable/c/11196ee3916e50a5da3c1e6ecda19a02dca14ba3 - https://git.kernel.org/stable/c/1a76cfc388cf105d3e04ac592670a52a3864b1ba - https://git.kernel.org/stable/c/41ddb251c68ac75c101d3a50a68c4629c9055e4c
CVE ID: CVE-2023-53438 State: PUBLISHED Published: 2025-09-18T16:04:16.501Z Last Updated: 2025-09-18T16:04:16.501Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/MCE: Always save CS register on AMD Zen IF Poison errors The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architectura
text. In other words, the exact rIP is not known, but the context is known to not have changed. There is no architecturally-defined method to determine this behavior. The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV]. Add a quirk to save the CS register for poison consumption from the IF unit banks. This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in k
eads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context. References: - https://git.kernel.org/stable/c/e6e6a5f50f58fadec397b23064b7e4830292863d - https://git.kernel.org/stable/c/6eac3965901489ae114a664a78cd2d1415d1af5c - https://git.kernel.org/stable/c/2e01bdf7203c383e9d8489d9f963c52d6c81e4db - https://git.kernel.org/stable/c/4240e2ebe67941ce2c4f5c866c3af4b5ac7a0c67
CVE ID: CVE-2023-53439 State: PUBLISHED Published: 2025-09-18T16:04:17.166Z Last Updated: 2025-09-18T16:04:17.166Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: skb_partial_csum_set() fix against transport header magic value skb->transport_header uses the special 0xFFFF value to mark if the transport header was set or not. We must prevent callers to accidentaly set skb->transport_header to 0xFFFF. Note that only fuzzers can possibly do this today. syzbot reported: WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline] WARNING: CPU: 0 PID: 2340 at include/linux/sk
ux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline] WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103 Modules linked in: CPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP: 0010:skb_transport_header include/linux/skbuff.h:2847 [inline] RIP: 0010:skb_transport_offset include/linux/skbuff.h:2956 [inline] RIP: 0010:virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103 Code: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 f
t.h:103 Code: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc <0f> 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f RSP: 0018:ffffc90004497880 EFLAGS: 00010293 RAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100 RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff RBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034 R10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8 R13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35 FS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080
5 FS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> packet_snd net/packet/af_packet.c:3076 [inline] packet_sendmsg+0x4590/0x61a0 net/packet/af_packet.c:3115 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] __sys_sendto+0x472/0x630 net/socket.c:2144 __do_sys_sendto net/socket.c:2156 [inline] __se_sys_sendto net/socket.c:2152 [inline] __x64_sys_sendto+0xe5/0x100 net/socket
_sys_sendto net/socket.c:2156 [inline] __se_sys_sendto net/socket.c:2152 [inline] __x64_sys_sendto+0xe5/0x100 net/socket.c:2152 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f9210c8c169 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9211a59168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169 RDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003 R
ffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169 RDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00007f9210ce7ca1 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe135d65cf R14: 00007f9211a59300 R15: 0000000000022000 References: - https://git.kernel.org/stable/c/3e785c8deb046305c61b9fa02265d0cb900c4a45 - https://git.kernel.org/stable/c/70a76d6816148819d0464f71aafa126c84826628 - https://git.kernel.org/stable/c/424f8416bb39936df6365442d651ee729b283460
CVE ID: CVE-2023-53440 State: PUBLISHED Published: 2025-09-18T16:04:17.845Z Last Updated: 2025-09-18T16:04:17.845Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix sysfs interface lifetime The current nilfs2 sysfs support has issues with the timing of creation and deletion of sysfs entries, potentially leading to null pointer dereferences, use-after-free, and lockdep warnings. Some of the sysfs attributes for nilfs2 per-filesystem instance refer to metadata file "cpfile", "sufile", or "dat", but nilfs_sysfs_create_device_group that creates those attributes is executed before the inodes for these metadata files are loa
s_sysfs_create_device_group that creates those attributes is executed before the inodes for these metadata files are loaded, and nilfs_sysfs_delete_device_group which deletes these sysfs entries is called after releasing their metadata file inodes. Therefore, access to some of these sysfs attributes may occur outside of the lifetime of these metadata files, resulting in inode NULL pointer dereferences or use-after-free. In addition, the call to nilfs_sysfs_create_device_group() is made during the locking period of the semaphore "ns_sem" of nilfs object, so the shrinker call caused by the memory allocation for the sysfs entries, may derive lock dependencies "ns_sem" -> (shrinker) -> "locks ac
caused by the memory allocation for the sysfs entries, may derive lock dependencies "ns_sem" -> (shrinker) -> "locks acquired in nilfs_evict_inode()". Since nilfs2 may acquire "ns_sem" deep in the call stack holding other locks via its error handler __nilfs_error(), this causes lockdep to report circular locking. This is a false positive and no circular locking actually occurs as no inodes exist yet when nilfs_sysfs_create_device_group() is called. Fortunately, the lockdep warnings can be resolved by simply moving the call to nilfs_sysfs_create_device_group() out of "ns_sem". This fixes these sysfs issues by revising where the device's sysfs interface is created/deleted and keeping its life
m". This fixes these sysfs issues by revising where the device's sysfs interface is created/deleted and keeping its lifetime within the lifetime of the metadata files above. References: - https://git.kernel.org/stable/c/d20dcec8f326deb77b6688f8441e014045dac457 - https://git.kernel.org/stable/c/5fe0ea141fbb887d407f1bf572ebf24427480d5c - https://git.kernel.org/stable/c/83b16a60e413148685739635901937e2f16a7873 - https://git.kernel.org/stable/c/3dbee84bf9e3273c4bb9ca6fc18ff22fba23dd24 - https://git.kernel.org/stable/c/d540aea451ab5489777a8156560f1388449b3109 - https://git.kernel.org/stable/c/1942ccb7d95f287a312fcbabfa8bc9ba501b1953 - https://git.kernel.org/stable/c/daf4eb3a908b108279b60172d2f176
l.org/stable/c/1942ccb7d95f287a312fcbabfa8bc9ba501b1953 - https://git.kernel.org/stable/c/daf4eb3a908b108279b60172d2f176e70d2df875 - https://git.kernel.org/stable/c/42560f9c92cc43dce75dbf06cc0d840dced39b12
CVE ID: CVE-2023-53441 State: PUBLISHED Published: 2025-09-18T16:04:18.519Z Last Updated: 2025-09-18T16:04:18.519Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: cpumap: Fix memory leak in cpu_map_update_elem Syzkaller reported a memory leak as follows: BUG: memory leak unreferenced object 0xff110001198ef748 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J........... 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(....... backtrace: [<ffffffffadd28087>] __cpu_map_entry_alloc+0xf7/0xb00 [<ffffffffadd28d8e>]
8e 19 01 00 11 ff ........(....... backtrace: [<ffffffffadd28087>] __cpu_map_entry_alloc+0xf7/0xb00 [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0 [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520 [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720 [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90 [<ffffffffb029cc80>] do_syscall_64+0x30/0x40 [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 BUG: memory leak unreferenced object 0xff110001198ef528 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffffadd281f0>] __cpu_map_entry_alloc+0x260/0xb00 [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0 [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520 [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720 [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90 [<ffffffffb029cc80>] do_syscall_64+0x30/0x40 [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 BUG: memory leak unreferenced object 0xff1100010fd93d68 (size 8): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........
"syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [<ffffffffade5db3e>] kvmalloc_node+0x11e/0x170 [<ffffffffadd28280>] __cpu_map_entry_alloc+0x2f0/0xb00 [<ffffffffadd28d8e>] cpu_map_update_elem+0x2fe/0x3d0 [<ffffffffadc6d0fd>] bpf_map_update_value.isra.0+0x2bd/0x520 [<ffffffffadc7349b>] map_update_elem+0x4cb/0x720 [<ffffffffadc7d983>] __se_sys_bpf+0x8c3/0xb90 [<ffffffffb029cc80>] do_syscall_64+0x30/0x40 [<ffffffffb0400099>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 In the cpu_map_update_elem flow, when kthread_stop is called before calling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit of kthread
, when kthread_stop is called before calling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bit of kthread has been set by kthread_stop, the threadfn of rcpu->kthread will never be executed, and rcpu->refcnt will never be 0, which will lead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot be released. Calling kthread_stop before executing kthread's threadfn will return -EINTR. We can complete the release of memory resources in this state. References: - https://git.kernel.org/stable/c/d26299f50f5ea8f0aeb5d49e659c31f64233c816 - https://git.kernel.org/stable/c/b11a9b4f28cb6ff69ef7e69809e5f7fffeac9030 - https://git.kernel.org/stable/c/a957ac8e0b5ffb5797382a6adbafd00
.org/stable/c/b11a9b4f28cb6ff69ef7e69809e5f7fffeac9030 - https://git.kernel.org/stable/c/a957ac8e0b5ffb5797382a6adbafd005a5f72851 - https://git.kernel.org/stable/c/4369016497319a9635702da010d02af1ebb1849d
CVE ID: CVE-2023-53442 State: PUBLISHED Published: 2025-09-18T16:04:19.192Z Last Updated: 2025-09-18T16:04:19.192Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: Block switchdev mode when ADQ is active and vice versa ADQ and switchdev are not supported simultaneously. Enabling both at the same time can result in nullptr dereference. To prevent this, check if ADQ is active when changing devlink mode to switchdev mode, and check if switchdev is active when enabling ADQ. References: - https://git.kernel.org/stable/c/1c82d1b736ce85e77fd4da05eca6f1f4a52a2bc3 - https://git.kernel.org/stable/c/24f0d69da35d812b3a1104918014a2962714
stable/c/1c82d1b736ce85e77fd4da05eca6f1f4a52a2bc3 - https://git.kernel.org/stable/c/24f0d69da35d812b3a1104918014a29627140cb1 - https://git.kernel.org/stable/c/43d00e102d9ecbe2635d7e3f2e14d2e90183d6af
CVE ID: CVE-2023-53443 State: PUBLISHED Published: 2025-09-18T16:04:19.884Z Last Updated: 2025-09-18T16:04:19.884Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get() as pm_runtime_get_sync() will increase the refcnt even when it returns an error. References: - https://git.kernel.org/stable/c/7195e642b49af60d4120fa1b45bd812ba528174f - https://git.kernel.org/stable/c/754e81ff44061dda68da0fd4ef51bd1aa9fbf2cf - https://git.kernel.org/stable/c/5a47bb71b1a94a279144fc3031d3c4591b38dd16 - https://git.ke
1dda68da0fd4ef51bd1aa9fbf2cf - https://git.kernel.org/stable/c/5a47bb71b1a94a279144fc3031d3c4591b38dd16 - https://git.kernel.org/stable/c/9893771097b22a8743a446e45994a177795ca4da - https://git.kernel.org/stable/c/dc9437e9889c3dacf1f320e3cf08da74127573fe - https://git.kernel.org/stable/c/4414a7ab80cebf715045e3c4d465feefbad21139
CVE ID: CVE-2023-53444 State: PUBLISHED Published: 2025-09-18T16:04:20.572Z Last Updated: 2025-09-18T16:04:20.572Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix bulk_move corruption when adding a entry When the resource is the first in the bulk_move range, adding it again (thus moving it to the tail) will corrupt the list since the first pointer is not moved. This eventually lead to null pointer deref in ttm_lru_bulk_move_del() References: - https://git.kernel.org/stable/c/70a3015683b007a0db4a1e858791b69afd45fc83 - https://git.kernel.org/stable/c/e7cf50e41bdc2d574056ebbfeaafc5f0e2562d5b - https://git.kernel.org/st
58791b69afd45fc83 - https://git.kernel.org/stable/c/e7cf50e41bdc2d574056ebbfeaafc5f0e2562d5b - https://git.kernel.org/stable/c/4481913607e58196c48a4fef5e6f45350684ec3c
CVE ID: CVE-2023-53445 State: PUBLISHED Published: 2025-09-18T16:04:21.257Z Last Updated: 2025-09-18T16:04:21.257Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Fix a refcount bug in qrtr_recvmsg() Syzbot reported a bug as following: refcount_t: addition on 0; use-after-free. ... RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25 ... Call Trace: <TASK> __refcount_add include/linux/refcount.h:199 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] kref_get include/linux/kref.h:45 [inline] qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline] qrtr_no
count.h:267 [inline] kref_get include/linux/kref.h:45 [inline] qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline] qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline] qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline] qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg+0xe2/0x160 net/socket.c:1038 qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688 process_one_work+0x991/0x15c0 kernel/workqueue.c:2390 worker_thread+0x669/0x1090 kernel/workqueue.c:2537 It occurs in the concurrent scenario of qrtr_recvmsg() and qrtr_endpoint_unregister() as following: cpu0 cpu1 qrtr_recvmsg qrtr_endpoint_unregister qrtr_send_resume_tx qrtr_node_release qrtr_node_l
gister() as following: cpu0 cpu1 qrtr_recvmsg qrtr_endpoint_unregister qrtr_send_resume_tx qrtr_node_release qrtr_node_lookup mutex_lock(&qrtr_node_lock) spin_lock_irqsave(&qrtr_nodes_lock, ) refcount_dec_and_test(&node->ref) [node->ref == 0] radix_tree_lookup [node != NULL] __qrtr_node_release qrtr_node_acquire spin_lock_irqsave(&qrtr_nodes_lock, ) kref_get(&node->ref) [WARNING] ... mutex_unlock(&qrtr_node_lock) Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this is actually improving the protection of node reference. References: - https://git.kernel.org/stable/c/98a9cd82c541ef6cbdb829cd6c05cbbb471e373c - https://git.kernel.org/stable/c/b9ba5906c42089f8e1d0001b7b50a7940f08
stable/c/98a9cd82c541ef6cbdb829cd6c05cbbb471e373c - https://git.kernel.org/stable/c/b9ba5906c42089f8e1d0001b7b50a7940f086cbb - https://git.kernel.org/stable/c/aa95efa187b4114075f312b3c4680d050b56fdec - https://git.kernel.org/stable/c/48a07f6e00d305597396da4d7494b81cec05b9d3 - https://git.kernel.org/stable/c/44d807320000db0d0013372ad39b53e12d52f758