Total
33454 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-48815 | 1 Linux | 1 Linux Kernel | 2025-10-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. | ||||
| CVE-2024-45244 | 1 Hyperledger | 1 Fabric | 2025-10-06 | 5.3 Medium |
| Hyperledger Fabric through 3.0.0 and 2.5.x through 2.5.9 do not verify that a request has a timestamp within the expected time window. | ||||
| CVE-2024-42260 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Validate passed in drm syncobj handles in the performance extension If userspace provides an unknown or invalid handle anywhere in the handle array the rest of the driver will not handle that well. Fix it by checking handle was looked up successfully or otherwise fail the extension by jumping into the existing unwind. (cherry picked from commit a546b7e4d73c23838d7e4d2c92882b3ca902d213) | ||||
| CVE-2024-42261 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Validate passed in drm syncobj handles in the timestamp extension If userspace provides an unknown or invalid handle anywhere in the handle array the rest of the driver will not handle that well. Fix it by checking handle was looked up successfully or otherwise fail the extension by jumping into the existing unwind. (cherry picked from commit 8d1276d1b8f738c3afe1457d4dff5cc66fc848a3) | ||||
| CVE-2024-42267 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel. | ||||
| CVE-2025-55553 | 2 Linuxfoundation, Pytorch | 2 Pytorch, Pytorch | 2025-10-03 | 7.5 High |
| A syntax error in the component proxy_tensor.py of pytorch v2.7.0 allows attackers to cause a Denial of Service (DoS). | ||||
| CVE-2025-55557 | 2 Linuxfoundation, Pytorch | 2 Pytorch, Pytorch | 2025-10-03 | 7.5 High |
| A Name Error occurs in pytorch v2.7.0 when a PyTorch model consists of torch.cummin and is compiled by Inductor, leading to a Denial of Service (DoS). | ||||
| CVE-2025-46148 | 2 Linuxfoundation, Pytorch | 2 Pytorch, Pytorch | 2025-10-03 | 5.3 Medium |
| In PyTorch through 2.6.0, when eager is used, nn.PairwiseDistance(p=2) produces incorrect results. | ||||
| CVE-2025-46150 | 2 Linuxfoundation, Pytorch | 2 Pytorch, Pytorch | 2025-10-03 | 5.3 Medium |
| In PyTorch before 2.7.0, when torch.compile is used, FractionalMaxPool2d has inconsistent results. | ||||
| CVE-2025-55551 | 2 Linuxfoundation, Pytorch | 2 Pytorch, Pytorch | 2025-10-03 | 7.5 High |
| An issue in the component torch.linalg.lu of pytorch v2.8.0 allows attackers to cause a Denial of Service (DoS) when performing a slice operation. | ||||
| CVE-2024-38620 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HCI: Remove HCI_AMP support Since BT_HS has been remove HCI_AMP controllers no longer has any use so remove it along with the capability of creating AMP controllers. Since we no longer need to differentiate between AMP and Primary controllers, as only HCI_PRIMARY is left, this also remove hdev->dev_type altogether. | ||||
| CVE-2025-54591 | 1 Freshrss | 1 Freshrss | 2025-10-03 | 7.5 High |
| FreshRSS is a free, self-hostable RSS aggregator. Versions 1.26.3 and below expose information about feeds and tags of default admin users, due to lack of access checking in the FreshRSS_Auth::hasAccess() function used by some of the tag/feed related endpoints. FreshRSS controllers usually have a defined firstAction() method with an override to make sure that every action requires access. If one doesn't, then every action has to check for access manually, and certain endpoints use neither the firstAction() method, or do they perform a manual access check. This issue is fixed in version 1.27.0. | ||||
| CVE-2025-54875 | 1 Freshrss | 1 Freshrss | 2025-10-03 | 9.8 Critical |
| FreshRSS is a free, self-hostable RSS aggregator. In versions 1.16.0 and above through 1.26.3, an unprivileged attacker can create a new admin user when registration is enabled through the use of a hidden field used only in the user management admin page, new_user_is_admin. This is fixed in version 1.27.0. | ||||
| CVE-2024-38614 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: openrisc: traps: Don't send signals to kernel mode threads OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error. This patch adds conditions to die if the kernel receives these exceptions in kernel mode code. | ||||
| CVE-2024-38607 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. | ||||
| CVE-2024-38604 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: block: refine the EOF check in blkdev_iomap_begin blkdev_iomap_begin rounds down the offset to the logical block size before stashing it in iomap->offset and checking that it still is inside the inode size. Check the i_size check to the raw pos value so that we don't try a zero size write if iter->pos is unaligned. | ||||
| CVE-2024-38663 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix list corruption from resetting io stat Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. | ||||
| CVE-2024-37026 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: Only use reserved BCS instances for usm migrate exec queue The GuC context scheduling queue is 2 entires deep, thus it is possible for a migration job to be stuck behind a fault if migration exec queue shares engines with user jobs. This can deadlock as the migrate exec queue is required to service page faults. Avoid deadlock by only using reserved BCS instances for usm migrate exec queue. (cherry picked from commit 04f4a70a183a688a60fe3882d6e4236ea02cfc67) | ||||
| CVE-2024-38636 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: multidev: fix to recognize valid zero block address As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below: ./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] null_blk: module loaded [ 4378.209860] null_blk: disk nullb0 created [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520] dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Call Trace: <TASK> __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2]. Quoted from reply of Shinichiro Kawasaki: "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff. I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached() modify map->m_pblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the whole f2fs, across the all block devices. It compares map->m_pblk against NULL_ADDR == 0, then go into the unexpected branch and sets the invalid iomap->length. The WARN catches the invalid iomap->length. This WARN is printed even for non-zoned block devices, by following steps. - Create two (non-zoned) null_blk devices memory backed with 128MB size each: nullb0 and nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mount_dir}" # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192 # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct ..." So, the root cause of this issue is: when multi-devices feature is on, f2fs_map_blocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fs_iomap_begin() treats it as an invalid block address, and then it triggers the warning in iomap framework code. Finally, as discussed, we decide to use a more simple and direct way that checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of (map.m_pblk != NULL_ADDR) to fix this issue. Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this issue. [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/ | ||||
| CVE-2024-38626 | 1 Linux | 1 Linux Kernel | 2025-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fuse: clear FR_SENT when re-adding requests into pending list The following warning was reported by lee bruce: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 8264 at fs/fuse/dev.c:300 fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300 Modules linked in: CPU: 0 PID: 8264 Comm: ab2 Not tainted 6.9.0-rc7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300 ...... Call Trace: <TASK> fuse_dev_do_read.constprop.0+0xd36/0x1dd0 fs/fuse/dev.c:1334 fuse_dev_read+0x166/0x200 fs/fuse/dev.c:1367 call_read_iter include/linux/fs.h:2104 [inline] new_sync_read fs/read_write.c:395 [inline] vfs_read+0x85b/0xba0 fs/read_write.c:476 ksys_read+0x12f/0x260 fs/read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xce/0x260 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...... </TASK> The warning is due to the FUSE_NOTIFY_RESEND notify sent by the write() syscall in the reproducer program and it happens as follows: (1) calls fuse_dev_read() to read the INIT request The read succeeds. During the read, bit FR_SENT will be set on the request. (2) calls fuse_dev_write() to send an USE_NOTIFY_RESEND notify The resend notify will resend all processing requests, so the INIT request is moved from processing list to pending list again. (3) calls fuse_dev_read() with an invalid output address fuse_dev_read() will try to copy the same INIT request to the output address, but it will fail due to the invalid address, so the INIT request is ended and triggers the warning in fuse_request_end(). Fix it by clearing FR_SENT when re-adding requests into pending list. | ||||