CVE-2025-15358 - DVP-12SE11T - Denial of Service Vulnerability
CVE ID : CVE-2025-15358
Published : Dec. 30, 2025, 9:15 a.m. | 48 minutes ago
Description : DVP-12SE11T - Denial of Service Vulnerability
Severity: 7.5 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-15358
Published : Dec. 30, 2025, 9:15 a.m. | 48 minutes ago
Description : DVP-12SE11T - Denial of Service Vulnerability
Severity: 7.5 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-15242 - PHPEMS Coupon race condition
CVE ID : CVE-2025-15242
Published : Dec. 30, 2025, 9:32 a.m. | 32 minutes ago
Description : A vulnerability was detected in PHPEMS up to 11.0. The impacted element is an unknown function of the component Coupon Handler. Performing manipulation results in race condition. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitability is regarded as difficult. The exploit is now public and may be used.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-15242
Published : Dec. 30, 2025, 9:32 a.m. | 32 minutes ago
Description : A vulnerability was detected in PHPEMS up to 11.0. The impacted element is an unknown function of the component Coupon Handler. Performing manipulation results in race condition. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitability is regarded as difficult. The exploit is now public and may be used.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54311 - ext4: fix deadlock when converting an inline directory in nojournal mode
CVE ID : CVE-2023-54311
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ext4: fix deadlock when converting an inline directory in nojournal mode In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock by calling ext4_handle_dirty_dirblock() when it already has taken the directory lock. There is a similar self-deadlock in ext4_incvert_inline_data_nolock() for data files which we'll fix at the same time. A simple reproducer demonstrating the problem: mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64 mount -t ext4 -o dirsync /dev/vdc /vdc cd /vdc mkdir file0 cd file0 touch file0 touch file1 attr -s BurnSpaceInEA -V abcde . touch supercalifragilisticexpialidocious
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54311
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ext4: fix deadlock when converting an inline directory in nojournal mode In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock by calling ext4_handle_dirty_dirblock() when it already has taken the directory lock. There is a similar self-deadlock in ext4_incvert_inline_data_nolock() for data files which we'll fix at the same time. A simple reproducer demonstrating the problem: mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64 mount -t ext4 -o dirsync /dev/vdc /vdc cd /vdc mkdir file0 cd file0 touch file0 touch file1 attr -s BurnSpaceInEA -V abcde . touch supercalifragilisticexpialidocious
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54312 - samples/bpf: Fix buffer overflow in tcp_basertt
CVE ID : CVE-2023-54312
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: samples/bpf: Fix buffer overflow in tcp_basertt Using sizeof(nv) or strlen(nv)+1 is correct.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54312
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: samples/bpf: Fix buffer overflow in tcp_basertt Using sizeof(nv) or strlen(nv)+1 is correct.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54313 - ovl: fix null pointer dereference in ovl_get_acl_rcu()
CVE ID : CVE-2023-54313
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ovl: fix null pointer dereference in ovl_get_acl_rcu() Following process: P1 P2 path_openat link_path_walk may_lookup inode_permission(rcu) ovl_permission acl_permission_check check_acl get_cached_acl_rcu ovl_get_inode_acl realinode = ovl_inode_real(ovl_inode) drop_cache __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_inode(ovl_inode) dput(oi->__upperdentry) dentry_kill(upperdentry) dentry_unlink_inode upperdentry->d_inode = NULL ovl_inode_upper upperdentry = ovl_i_dentry_upper(ovl_inode) d_inode(upperdentry) // returns NULL IS_POSIXACL(realinode) // NULL pointer dereference , will trigger an null pointer dereference at realinode: [ 205.472797] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted 6.3.0-12064-g2edfa098e750-dirty #1216 [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300 [ 205.489584] Call Trace: [ 205.489812] [ 205.490014] ovl_get_inode_acl+0x26/0x30 [ 205.490466] get_cached_acl_rcu+0x61/0xa0 [ 205.490908] generic_permission+0x1bf/0x4e0 [ 205.491447] ovl_permission+0x79/0x1b0 [ 205.491917] inode_permission+0x15e/0x2c0 [ 205.492425] link_path_walk+0x115/0x550 [ 205.493311] path_lookupat.isra.0+0xb2/0x200 [ 205.493803] filename_lookup+0xda/0x240 [ 205.495747] vfs_fstatat+0x7b/0xb0 Fetch a reproducer in [Link]. Use the helper ovl_i_path_realinode() to get realinode and then do non-nullptr checking.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54313
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ovl: fix null pointer dereference in ovl_get_acl_rcu() Following process: P1 P2 path_openat link_path_walk may_lookup inode_permission(rcu) ovl_permission acl_permission_check check_acl get_cached_acl_rcu ovl_get_inode_acl realinode = ovl_inode_real(ovl_inode) drop_cache __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_inode(ovl_inode) dput(oi->__upperdentry) dentry_kill(upperdentry) dentry_unlink_inode upperdentry->d_inode = NULL ovl_inode_upper upperdentry = ovl_i_dentry_upper(ovl_inode) d_inode(upperdentry) // returns NULL IS_POSIXACL(realinode) // NULL pointer dereference , will trigger an null pointer dereference at realinode: [ 205.472797] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted 6.3.0-12064-g2edfa098e750-dirty #1216 [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300 [ 205.489584] Call Trace: [ 205.489812] [ 205.490014] ovl_get_inode_acl+0x26/0x30 [ 205.490466] get_cached_acl_rcu+0x61/0xa0 [ 205.490908] generic_permission+0x1bf/0x4e0 [ 205.491447] ovl_permission+0x79/0x1b0 [ 205.491917] inode_permission+0x15e/0x2c0 [ 205.492425] link_path_walk+0x115/0x550 [ 205.493311] path_lookupat.isra.0+0xb2/0x200 [ 205.493803] filename_lookup+0xda/0x240 [ 205.495747] vfs_fstatat+0x7b/0xb0 Fetch a reproducer in [Link]. Use the helper ovl_i_path_realinode() to get realinode and then do non-nullptr checking.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54314 - media: af9005: Fix null-ptr-deref in af9005_i2c_xfer
CVE ID : CVE-2023-54314
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: af9005: Fix null-ptr-deref in af9005_i2c_xfer In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9005_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54314
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: media: af9005: Fix null-ptr-deref in af9005_i2c_xfer In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9005_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54315 - powerpc/powernv/sriov: perform null check on iov before dereferencing iov
CVE ID : CVE-2023-54315
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/sriov: perform null check on iov before dereferencing iov Currently pointer iov is being dereferenced before the null check of iov which can lead to null pointer dereference errors. Fix this by moving the iov null check before the dereferencing. Detected using cppcheck static analysis: linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either the condition '!iov' is redundant or there is possible null pointer dereference: iov. [nullPointerRedundantCheck] num_vfs = iov->num_vfs; ^
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54315
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/sriov: perform null check on iov before dereferencing iov Currently pointer iov is being dereferenced before the null check of iov which can lead to null pointer dereference errors. Fix this by moving the iov null check before the dereferencing. Detected using cppcheck static analysis: linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either the condition '!iov' is redundant or there is possible null pointer dereference: iov. [nullPointerRedundantCheck] num_vfs = iov->num_vfs; ^
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54316 - refscale: Fix uninitalized use of wait_queue_head_t
CVE ID : CVE-2023-54316
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: refscale: Fix uninitalized use of wait_queue_head_t Running the refscale test occasionally crashes the kernel with the following error: [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF: error_code(0x0000) - not-present page [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0 [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021 [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 : [ 8569.952940] Call Trace: [ 8569.952941] [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale] [ 8569.952959] kthread+0x10e/0x130 [ 8569.952966] ret_from_fork+0x1f/0x30 [ 8569.952973] The likely cause is that init_waitqueue_head() is called after the call to the torture_create_kthread() function that creates the ref_scale_reader kthread. Although this init_waitqueue_head() call will very likely complete before this kthread is created and starts running, it is possible that the calling kthread will be delayed between the calls to torture_create_kthread() and init_waitqueue_head(). In this case, the new kthread will use the waitqueue head before it is properly initialized, which is not good for the kernel's health and well-being. The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here The offset of flags from list_head entry in wait_queue_entry is -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task structure is zero initialized, the instruction will try to access address 0xffffffffffffffe8, which is exactly the fault address listed above. This commit therefore invokes init_waitqueue_head() before creating the kthread.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54316
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: refscale: Fix uninitalized use of wait_queue_head_t Running the refscale test occasionally crashes the kernel with the following error: [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF: error_code(0x0000) - not-present page [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0 [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021 [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 : [ 8569.952940] Call Trace: [ 8569.952941] [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale] [ 8569.952959] kthread+0x10e/0x130 [ 8569.952966] ret_from_fork+0x1f/0x30 [ 8569.952973] The likely cause is that init_waitqueue_head() is called after the call to the torture_create_kthread() function that creates the ref_scale_reader kthread. Although this init_waitqueue_head() call will very likely complete before this kthread is created and starts running, it is possible that the calling kthread will be delayed between the calls to torture_create_kthread() and init_waitqueue_head(). In this case, the new kthread will use the waitqueue head before it is properly initialized, which is not good for the kernel's health and well-being. The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here The offset of flags from list_head entry in wait_queue_entry is -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task structure is zero initialized, the instruction will try to access address 0xffffffffffffffe8, which is exactly the fault address listed above. This commit therefore invokes init_waitqueue_head() before creating the kthread.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54317 - dm flakey: don't corrupt the zero page
CVE ID : CVE-2023-54317
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: dm flakey: don't corrupt the zero page When we need to zero some range on a block device, the function __blkdev_issue_zero_pages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory. Fix this bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54317
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: dm flakey: don't corrupt the zero page When we need to zero some range on a block device, the function __blkdev_issue_zero_pages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory. Fix this bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54318 - net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add
CVE ID : CVE-2023-54318
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add While doing smcr_port_add, there maybe linkgroup add into or delete from smc_lgr_list.list at the same time, which may result kernel crash. So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add. The crash calltrace show below: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014 Workqueue: events smc_ib_port_event_work [smc] RIP: 0010:smcr_port_add+0xa6/0xf0 [smc] RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918 R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4 R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08 FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0 PKRU: 55555554 Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54318
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add While doing smcr_port_add, there maybe linkgroup add into or delete from smc_lgr_list.list at the same time, which may result kernel crash. So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add. The crash calltrace show below: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014 Workqueue: events smc_ib_port_event_work [smc] RIP: 0010:smcr_port_add+0xa6/0xf0 [smc] RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918 R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4 R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08 FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0 PKRU: 55555554 Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54319 - pinctrl: at91-pio4: check return value of devm_kasprintf()
CVE ID : CVE-2023-54319
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91-pio4: check return value of devm_kasprintf() devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Depends-on: 1c4e5c470a56 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks") Depends-on: 5a8f9cf269e8 ("pinctrl: at91-pio4: use proper format specifier for unsigned int")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54319
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91-pio4: check return value of devm_kasprintf() devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Depends-on: 1c4e5c470a56 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks") Depends-on: 5a8f9cf269e8 ("pinctrl: at91-pio4: use proper format specifier for unsigned int")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54320 - platform/x86/amd: pmc: Fix memory leak in amd_pmc_stb_debugfs_open_v2()
CVE ID : CVE-2023-54320
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd: pmc: Fix memory leak in amd_pmc_stb_debugfs_open_v2() Function amd_pmc_stb_debugfs_open_v2() may be called when the STB debug mechanism enabled. When amd_pmc_send_cmd() fails, the 'buf' needs to be released.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54320
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd: pmc: Fix memory leak in amd_pmc_stb_debugfs_open_v2() Function amd_pmc_stb_debugfs_open_v2() may be called when the STB debug mechanism enabled. When amd_pmc_send_cmd() fails, the 'buf' needs to be released.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54321 - driver core: fix potential null-ptr-deref in device_add()
CVE ID : CVE-2023-54321
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential null-ptr-deref in device_add() I got the following null-ptr-deref report while doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482] This is how it happened: w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device. // error path bus_remove_device() // The dev->driver is not null, but driver is not bound. __device_release_driver() klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref. // normal path bus_probe_device() // It's not called yet. device_bind_driver() If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54321
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential null-ptr-deref in device_add() I got the following null-ptr-deref report while doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482] This is how it happened: w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device. // error path bus_remove_device() // The dev->driver is not null, but driver is not bound. __device_release_driver() klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref. // normal path bus_probe_device() // It's not called yet. device_bind_driver() If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54323 - cxl/pmem: Fix nvdimm registration races
CVE ID : CVE-2023-54323
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: cxl/pmem: Fix nvdimm registration races A loop of the form: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done ...fails with the following crash signature: BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core] [..] Call Trace: cxl_pmem_ctl+0x121/0x240 [cxl_pmem] nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm] nd_label_data_init+0x135/0x7e0 [libnvdimm] nvdimm_probe+0xd6/0x1c0 [libnvdimm] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __device_attach_driver+0x85/0x110 bus_for_each_drv+0x7d/0xc0 __device_attach+0xb4/0x1e0 bus_probe_device+0x9f/0xc0 device_add+0x445/0x9c0 nd_async_device_register+0xe/0x40 [libnvdimm] async_run_entry_fn+0x30/0x130 ...namely that the bottom half of async nvdimm device registration runs after the CXL has already torn down the context that cxl_pmem_ctl() needs. Unlike the ACPI NFIT case that benefits from launching multiple nvdimm device registrations in parallel from those listed in the table, CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for a synchronous registration path to preclude this scenario.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54323
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: cxl/pmem: Fix nvdimm registration races A loop of the form: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done ...fails with the following crash signature: BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core] [..] Call Trace: cxl_pmem_ctl+0x121/0x240 [cxl_pmem] nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm] nd_label_data_init+0x135/0x7e0 [libnvdimm] nvdimm_probe+0xd6/0x1c0 [libnvdimm] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __device_attach_driver+0x85/0x110 bus_for_each_drv+0x7d/0xc0 __device_attach+0xb4/0x1e0 bus_probe_device+0x9f/0xc0 device_add+0x445/0x9c0 nd_async_device_register+0xe/0x40 [libnvdimm] async_run_entry_fn+0x30/0x130 ...namely that the bottom half of async nvdimm device registration runs after the CXL has already torn down the context that cxl_pmem_ctl() needs. Unlike the ACPI NFIT case that benefits from launching multiple nvdimm device registrations in parallel from those listed in the table, CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for a synchronous registration path to preclude this scenario.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54324 - dm: fix a race condition in retrieve_deps
CVE ID : CVE-2023-54324
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: dm: fix a race condition in retrieve_deps There's a race condition in the multipath target when retrieve_deps races with multipath_message calling dm_get_device and dm_put_device. retrieve_deps walks the list of open devices without holding any lock but multipath may add or remove devices to the list while it is running. The end result may be memory corruption or use-after-free memory access. See this description of a UAF with multipath_message(): https://listman.redhat.com/archives/dm-devel/2022-October/052373.html Fix this bug by introducing a new rw semaphore "devices_lock". We grab devices_lock for read in retrieve_deps and we grab it for write in dm_get_device and dm_put_device.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54324
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: dm: fix a race condition in retrieve_deps There's a race condition in the multipath target when retrieve_deps races with multipath_message calling dm_get_device and dm_put_device. retrieve_deps walks the list of open devices without holding any lock but multipath may add or remove devices to the list while it is running. The end result may be memory corruption or use-after-free memory access. See this description of a UAF with multipath_message(): https://listman.redhat.com/archives/dm-devel/2022-October/052373.html Fix this bug by introducing a new rw semaphore "devices_lock". We grab devices_lock for read in retrieve_deps and we grab it for write in dm_get_device and dm_put_device.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54325 - crypto: qat - fix out-of-bounds read
CVE ID : CVE-2023-54325
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix out-of-bounds read When preparing an AER-CTR request, the driver copies the key provided by the user into a data structure that is accessible by the firmware. If the target device is QAT GEN4, the key size is rounded up by 16 since a rounded up size is expected by the device. If the key size is rounded up before the copy, the size used for copying the key might be bigger than the size of the region containing the key, causing an out-of-bounds read. Fix by doing the copy first and then update the keylen. This is to fix the following warning reported by KASAN: [ 138.150574] BUG: KASAN: global-out-of-bounds in qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat] [ 138.150641] Read of size 32 at addr ffffffff88c402c0 by task cryptomgr_test/2340 [ 138.150651] CPU: 15 PID: 2340 Comm: cryptomgr_test Not tainted 6.2.0-rc1+ #45 [ 138.150659] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022 [ 138.150663] Call Trace: [ 138.150668] [ 138.150922] kasan_check_range+0x13a/0x1c0 [ 138.150931] memcpy+0x1f/0x60 [ 138.150940] qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat] [ 138.151006] qat_alg_skcipher_init_sessions+0xc1/0x240 [intel_qat] [ 138.151073] crypto_skcipher_setkey+0x82/0x160 [ 138.151085] ? prepare_keybuf+0xa2/0xd0 [ 138.151095] test_skcipher_vec_cfg+0x2b8/0x800
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54325
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix out-of-bounds read When preparing an AER-CTR request, the driver copies the key provided by the user into a data structure that is accessible by the firmware. If the target device is QAT GEN4, the key size is rounded up by 16 since a rounded up size is expected by the device. If the key size is rounded up before the copy, the size used for copying the key might be bigger than the size of the region containing the key, causing an out-of-bounds read. Fix by doing the copy first and then update the keylen. This is to fix the following warning reported by KASAN: [ 138.150574] BUG: KASAN: global-out-of-bounds in qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat] [ 138.150641] Read of size 32 at addr ffffffff88c402c0 by task cryptomgr_test/2340 [ 138.150651] CPU: 15 PID: 2340 Comm: cryptomgr_test Not tainted 6.2.0-rc1+ #45 [ 138.150659] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022 [ 138.150663] Call Trace: [ 138.150668] [ 138.150922] kasan_check_range+0x13a/0x1c0 [ 138.150931] memcpy+0x1f/0x60 [ 138.150940] qat_alg_skcipher_init_com.isra.0+0x197/0x250 [intel_qat] [ 138.151006] qat_alg_skcipher_init_sessions+0xc1/0x240 [intel_qat] [ 138.151073] crypto_skcipher_setkey+0x82/0x160 [ 138.151085] ? prepare_keybuf+0xa2/0xd0 [ 138.151095] test_skcipher_vec_cfg+0x2b8/0x800
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2023-54326 - misc: pci_endpoint_test: Free IRQs before removing the device
CVE ID : CVE-2023-54326
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Free IRQs before removing the device In pci_endpoint_test_remove(), freeing the IRQs after removing the device creates a small race window for IRQs to be received with the test device memory already released, causing the IRQ handler to access invalid memory, resulting in an oops. Free the device IRQs before removing the device to avoid this issue.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2023-54326
Published : Dec. 30, 2025, 1:16 p.m. | 48 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: misc: pci_endpoint_test: Free IRQs before removing the device In pci_endpoint_test_remove(), freeing the IRQs after removing the device creates a small race window for IRQs to be received with the test device memory already released, causing the IRQ handler to access invalid memory, resulting in an oops. Free the device IRQs before removing the device to avoid this issue.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2024-58242 - I cannot create a title for a non-existent vulnerability.
CVE ID : CVE-2024-58242
Published : Dec. 30, 2025, 1:16 p.m. | 47 minutes ago
Description : Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2024. Notes: none.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2024-58242
Published : Dec. 30, 2025, 1:16 p.m. | 47 minutes ago
Description : Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2024. Notes: none.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2024-58243 - None
CVE ID : CVE-2024-58243
Published : Dec. 30, 2025, 1:16 p.m. | 47 minutes ago
Description : Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2024. Notes: none.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2024-58243
Published : Dec. 30, 2025, 1:16 p.m. | 47 minutes ago
Description : Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2024. Notes: none.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2024-58244 - Apache None
CVE ID : CVE-2024-58244
Published : Dec. 30, 2025, 1:16 p.m. | 47 minutes ago
Description : Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2024. Notes: none.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2024-58244
Published : Dec. 30, 2025, 1:16 p.m. | 47 minutes ago
Description : Rejected reason: ** REJECT ** DO NOT USE THIS CVE RECORD. ConsultIDs: none. Reason: This record was in a CNA pool that was not assigned to any issues during 2024. Notes: none.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...