CVE-2025-22021 - Kubernetes Cilium Envoy IPv6 SNAT Socket Vulnerability
CVE ID : CVE-2025-22021
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: netfilter: socket: Lookup orig tuple for IPv6 SNAT nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent. However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6. IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on `-m socket --transparent` and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22021
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: netfilter: socket: Lookup orig tuple for IPv6 SNAT nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent. However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6. IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on `-m socket --transparent` and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22023 - XHCI USB Driver Isochronous Transfer Ring Buffer Data Loss and UAF Vulnerability
CVE ID : CVE-2025-22023
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Don't skip on Stopped - Length Invalid Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped") in v6.11, the driver didn't skip missed isochronous TDs when handling Stoppend and Stopped - Length Invalid events. Instead, it erroneously cleared the skip flag, which would cause the ring to get stuck, as future events won't match the missed TD which is never removed from the queue until it's cancelled. This buggy logic seems to have been in place substantially unchanged since the 3.x series over 10 years ago, which probably speaks first and foremost about relative rarity of this case in normal usage, but by the spec I see no reason why it shouldn't be possible. After d56b0b2ab142, TDs are immediately skipped when handling those Stopped events. This poses a potential problem in case of Stopped - Length Invalid, which occurs either on completed TDs (likely already given back) or Link and No-Op TRBs. Such event won't be recognized as matching any TD (unless it's the rare Link TRB inside a TD) and will result in skipping all pending TDs, giving them back possibly before they are done, risking isoc data loss and maybe UAF by HW. As a compromise, don't skip and don't clear the skip flag on this kind of event. Then the next event will skip missed TDs. A downside of not handling Stopped - Length Invalid on a Link inside a TD is that if the TD is cancelled, its actual length will not be updated to account for TRBs (silently) completed before the TD was stopped. I had no luck producing this sequence of completion events so there is no compelling demonstration of any resulting disaster. It may be a very rare, obscure condition. The sole motivation for this patch is that if such unlikely event does occur, I'd rather risk reporting a cancelled partially done isoc frame as empty than gamble with UAF. This will be fixed more properly by looking at Stopped event's TRB pointer when making skipping decisions, but such rework is unlikely to be backported to v6.12, which will stay around for a few years.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22023
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Don't skip on Stopped - Length Invalid Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped") in v6.11, the driver didn't skip missed isochronous TDs when handling Stoppend and Stopped - Length Invalid events. Instead, it erroneously cleared the skip flag, which would cause the ring to get stuck, as future events won't match the missed TD which is never removed from the queue until it's cancelled. This buggy logic seems to have been in place substantially unchanged since the 3.x series over 10 years ago, which probably speaks first and foremost about relative rarity of this case in normal usage, but by the spec I see no reason why it shouldn't be possible. After d56b0b2ab142, TDs are immediately skipped when handling those Stopped events. This poses a potential problem in case of Stopped - Length Invalid, which occurs either on completed TDs (likely already given back) or Link and No-Op TRBs. Such event won't be recognized as matching any TD (unless it's the rare Link TRB inside a TD) and will result in skipping all pending TDs, giving them back possibly before they are done, risking isoc data loss and maybe UAF by HW. As a compromise, don't skip and don't clear the skip flag on this kind of event. Then the next event will skip missed TDs. A downside of not handling Stopped - Length Invalid on a Link inside a TD is that if the TD is cancelled, its actual length will not be updated to account for TRBs (silently) completed before the TD was stopped. I had no luck producing this sequence of completion events so there is no compelling demonstration of any resulting disaster. It may be a very rare, obscure condition. The sole motivation for this patch is that if such unlikely event does occur, I'd rather risk reporting a cancelled partially done isoc frame as empty than gamble with UAF. This will be fixed more properly by looking at Stopped event's TRB pointer when making skipping decisions, but such rework is unlikely to be backported to v6.12, which will stay around for a few years.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-30960 - FS Poster Unauthorized Access Vulnerability
CVE ID : CVE-2025-30960
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : Missing Authorization vulnerability in NotFound FS Poster. This issue affects FS Poster: from n/a through 6.5.8.
Severity: 8.3 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-30960
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : Missing Authorization vulnerability in NotFound FS Poster. This issue affects FS Poster: from n/a through 6.5.8.
Severity: 8.3 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-3682 - PCMan FTP Server PASV Command Handler Buffer Overflow Vulnerability
CVE ID : CVE-2025-3682
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability was found in PCMan FTP Server 2.0.7. It has been classified as critical. This affects an unknown part of the component PASV Command Handler. The manipulation leads to buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
Severity: 7.3 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-3682
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability was found in PCMan FTP Server 2.0.7. It has been classified as critical. This affects an unknown part of the component PASV Command Handler. The manipulation leads to buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
Severity: 7.3 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-3683 - PCMan FTP Server Buffer Overflow Vulnerability
CVE ID : CVE-2025-3683
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability was found in PCMan FTP Server 2.0.7. It has been declared as critical. This vulnerability affects unknown code of the component SIZE Command Handler. The manipulation leads to buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
Severity: 7.3 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-3683
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability was found in PCMan FTP Server 2.0.7. It has been declared as critical. This vulnerability affects unknown code of the component SIZE Command Handler. The manipulation leads to buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
Severity: 7.3 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-3684 - Xianqi Kindergarten Management System SQL Injection Vulnerability
CVE ID : CVE-2025-3684
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability was found in Xianqi Kindergarten Management System 2.0 Bulid 20190808. It has been rated as critical. This issue affects some unknown processing of the file stu_list.php of the component Child Management. The manipulation of the argument sex leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Other parameters might be affected as well.
Severity: 6.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-3684
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability was found in Xianqi Kindergarten Management System 2.0 Bulid 20190808. It has been rated as critical. This issue affects some unknown processing of the file stu_list.php of the component Child Management. The manipulation of the argument sex leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Other parameters might be affected as well.
Severity: 6.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-3685 - Code-projects Patient Record Management System SQL Injection Vulnerability
CVE ID : CVE-2025-3685
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability classified as critical has been found in code-projects Patient Record Management System 1.0. Affected is an unknown function of the file /edit_fpatient.php. The manipulation of the argument ID leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.
Severity: 6.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-3685
Published : April 16, 2025, 11:15 a.m. | 1 hour, 19 minutes ago
Description : A vulnerability classified as critical has been found in code-projects Patient Record Management System 1.0. Affected is an unknown function of the file /edit_fpatient.php. The manipulation of the argument ID leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.
Severity: 6.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-3686 - Misstt123 Oasys Path Traversal Remote Vulnerability
CVE ID : CVE-2025-3686
Published : April 16, 2025, 12:15 p.m. | 20 minutes ago
Description : A vulnerability classified as problematic was found in misstt123 oasys 1.0. Affected by this vulnerability is the function image of the file /show. The manipulation leads to path traversal. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. This product does not use versioning. This is why information about affected and unaffected releases are unavailable.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-3686
Published : April 16, 2025, 12:15 p.m. | 20 minutes ago
Description : A vulnerability classified as problematic was found in misstt123 oasys 1.0. Affected by this vulnerability is the function image of the file /show. The manipulation leads to path traversal. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. This product does not use versioning. This is why information about affected and unaffected releases are unavailable.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-3687 - Misstt123 Oasys Cross-Site Request Forgery Vulnerability
CVE ID : CVE-2025-3687
Published : April 16, 2025, 12:15 p.m. | 20 minutes ago
Description : A vulnerability, which was classified as problematic, has been found in misstt123 oasys 1.0. Affected by this issue is some unknown functionality of the component Sticky Notes Handler. The manipulation leads to cross-site request forgery. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-3687
Published : April 16, 2025, 12:15 p.m. | 20 minutes ago
Description : A vulnerability, which was classified as problematic, has been found in misstt123 oasys 1.0. Affected by this issue is some unknown functionality of the component Sticky Notes Handler. The manipulation leads to cross-site request forgery. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available.
Severity: 4.3 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-3688 - Mirweiye Seven Bears Library CMS Cross Site Scripting Vulnerability
CVE ID : CVE-2025-3688
Published : April 16, 2025, 12:15 p.m. | 20 minutes ago
Description : A vulnerability, which was classified as problematic, was found in mirweiye Seven Bears Library CMS 2023. This affects an unknown part of the component Background Management Page. The manipulation leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
Severity: 2.4 | LOW
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-3688
Published : April 16, 2025, 12:15 p.m. | 20 minutes ago
Description : A vulnerability, which was classified as problematic, was found in mirweiye Seven Bears Library CMS 2023. This affects an unknown part of the component Background Management Page. The manipulation leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.
Severity: 2.4 | LOW
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22121 - Linux Kernel ext4 Use-After-Free Vulnerability
CVE ID : CVE-2025-22121
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22121
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all() There's issue as follows: BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172 CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Above issue happens as ext4_xattr_delete_inode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattr_check_inode() check if xattr if valid in inode. In fact, we can directly verify in ext4_iget_extra_inode(), so that there is no divergent verification.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22122 - Linux Kernel Block Buffer Overflow Vulnerability
CVE ID : CVE-2025-22122
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: block: fix adding folio to bio >4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage is supported, then 'offset' of folio can't be held in 'unsigned int', cause warning in bio_add_folio_nofail() and IO failure. Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't be overflow, and folio can be added to bio successfully.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22122
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: block: fix adding folio to bio >4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage is supported, then 'offset' of folio can't be held in 'unsigned int', cause warning in bio_add_folio_nofail() and IO failure. Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't be overflow, and folio can be added to bio successfully.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22123 - Linux F2FS Uninitialized Pointer Access Vulnerability
CVE ID : CVE-2025-22123
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid accessing uninitialized curseg syzbot reports a f2fs bug as below: F2FS-fs (loop3): Stopped filesystem due to reason: 7 kworker/u8:7: attempt to access beyond end of device BUG: unable to handle page fault for address: ffffed1604ea3dfa RIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline] RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline] RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline] RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline] RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649 f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline] f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791 write_inode fs/fs-writeback.c:1525 [inline] __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745 writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976 wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156 wb_do_writeback fs/fs-writeback.c:2303 [inline] wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Commit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") allows to trigger no free segment fault in allocator, then it will update curseg->segno to NULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed to check the flag, and access invalid curseg->segno directly in below call path, then resulting in panic: - f2fs_write_inode - f2fs_is_checkpoint_ready - has_enough_free_secs - has_not_enough_free_secs - __get_secs_required - has_curseg_enough_space - get_ckpt_valid_blocks : access invalid curseg->segno To avoid this issue, let's: - check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in f2fs_write_inode(). - in has_curseg_enough_space(), save curseg->segno into a temp variable, and verify its validation before use.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22123
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid accessing uninitialized curseg syzbot reports a f2fs bug as below: F2FS-fs (loop3): Stopped filesystem due to reason: 7 kworker/u8:7: attempt to access beyond end of device BUG: unable to handle page fault for address: ffffed1604ea3dfa RIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline] RIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline] RIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline] RIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline] RIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649 f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline] f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791 write_inode fs/fs-writeback.c:1525 [inline] __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745 writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976 wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156 wb_do_writeback fs/fs-writeback.c:2303 [inline] wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Commit 8b10d3653735 ("f2fs: introduce FAULT_NO_SEGMENT") allows to trigger no free segment fault in allocator, then it will update curseg->segno to NULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed to check the flag, and access invalid curseg->segno directly in below call path, then resulting in panic: - f2fs_write_inode - f2fs_is_checkpoint_ready - has_enough_free_secs - has_not_enough_free_secs - __get_secs_required - has_curseg_enough_space - get_ckpt_valid_blocks : access invalid curseg->segno To avoid this issue, let's: - check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in f2fs_write_inode(). - in has_curseg_enough_space(), save curseg->segno into a temp variable, and verify its validation before use.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22124 - Linux Kernel Clustermd Memory Corruption Vulnerability
CVE ID : CVE-2025-22124
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22124
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix wrong bitmap_limit for clustermd when write sb In clustermd, separate write-intent-bitmaps are used for each cluster node: 0 4k 8k 12k ------------------------------------------------------------------- | idle | md super | bm super [0] + bits | | bm bits[0, contd] | bm super[1] + bits | bm bits[1, contd] | | bm super[2] + bits | bm bits [2, contd] | bm super[3] + bits | | bm bits [3, contd] | | | So in node 1, pg_index in __write_sb_page() could equal to bitmap->storage.file_pages. Then bitmap_limit will be calculated to 0. md_super_write() will be called with 0 size. That means the first 4k sb area of node 1 will never be updated through filemap_write_page(). This bug causes hang of mdadm/clustermd_tests/01r1_Grow_resize. Here use (pg_index % bitmap->storage.file_pages) to make calculation of bitmap_limit correct.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22125 - "Linux MD RAID: Ignored IO Flags Vulnerability"
CVE ID : CVE-2025-22125
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: don't ignore IO flags If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22125
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: md/raid1,raid10: don't ignore IO flags If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced. Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks. Fix those problems by keep IO flags from master bio. Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22126 - Linux Kernel MD Device UAF Vulnerability
CVE ID : CVE-2025-22126
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: md: fix mddev uaf while iterating all_mddevs list While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22126
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: md: fix mddev uaf while iterating all_mddevs list While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF: t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex. Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22127 - F2FS Compression Vulnerability
CVE ID : CVE-2025-22127
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadloop in prepare_compress_overwrite() Jan Prusakowski reported a kernel hang issue as below: When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are: MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 wb_writeback+0xb0/0x410 wb_do_writeback+0x47/0x2f0 wb_workfn+0x5a/0x1c0 process_one_work+0x223/0x5b0 worker_thread+0x1d5/0x3c0 kthread+0xfd/0x230 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks. Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22127
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadloop in prepare_compress_overwrite() Jan Prusakowski reported a kernel hang issue as below: When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are: MKFS_OPTIONS -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace: __schedule+0x309/0x8e0 schedule+0x3a/0x100 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x59a/0xdb0 __f2fs_write_data_pages+0x3ac/0x400 do_writepages+0xe8/0x290 __writeback_single_inode+0x5c/0x360 writeback_sb_inodes+0x22f/0x570 wb_writeback+0xb0/0x410 wb_do_writeback+0x47/0x2f0 wb_workfn+0x5a/0x1c0 process_one_work+0x223/0x5b0 worker_thread+0x1d5/0x3c0 kthread+0xfd/0x230 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks. Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages().
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-22128 - "Linux Kernel ath12k WiFi Shared IRQ Affinity Hint Vulnerability"
CVE ID : CVE-2025-22128
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath12k_pci_msi_alloc(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the IRQ: kernel/irq/manage.c: /* make sure affinity_hint is cleaned up */ if (WARN_ON_ONCE(desc->affinity_hint)) desc->affinity_hint = NULL; So to fix this issue, clear the IRQ affinity hint before calling ath12k_pci_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-22128
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Clear affinity hint before calling ath12k_pci_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath12k_pci_msi_alloc(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This may end up with a warning from the IRQ core that is expecting the affinity hint to be cleared before freeing the IRQ: kernel/irq/manage.c: /* make sure affinity_hint is cleaned up */ if (WARN_ON_ONCE(desc->affinity_hint)) desc->affinity_hint = NULL; So to fix this issue, clear the IRQ affinity hint before calling ath12k_pci_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-23129 - "Qualcomm Atheros WiFi Kernel IRQ Affinity Hint Clearing Vulnerability"
CVE ID : CVE-2025-23129
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-23129
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2025-23130 - F2FS Linux Kernel Pinfile Allocation Vulnerability
CVE ID : CVE-2025-23130
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic once fallocation fails for pinfile syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg()
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID : CVE-2025-23130
Published : April 16, 2025, 3:16 p.m. | 1 hour, 20 minutes ago
Description : In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid panic once fallocation fails for pinfile syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210 f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238 f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830 f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940 vfs_fallocate+0x569/0x6e0 fs/open.c:327 do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885 __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation. In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg()
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...