p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-kvm · Page n° 196

Vulnérabilités publiées pour linux-kvm au cours des 30 derniers jours : 323. Présentes dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 5667

  1. CVE-2025-22104

    Élevée · CVSS 7.1EPSS 0,23%Aucun correctif publié

    ibmvnic: Use kernel helpers for hex dumps

    In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Use kernel helpers for hex dumps Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible. Therefore, create a new ibmvnic function that loops over a buffer and calls hex_dump_to_buffer instead. This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006

    Publication Mise à jour
  2. CVE-2025-22090

    Élevée · CVSS 7.3EPSS 0,21%Aucun correctif publié

    x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()

    In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range() If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is

    Publication Mise à jour
  3. CVE-2025-22086

    Élevée · CVSS 8.8EPSS 0,29%Aucun correctif publié

    RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow

    In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have. The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5_ib_qp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5_core_qp which is our FW QP number. Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace be

    Publication Mise à jour
  4. CVE-2025-22083

    Élevée · CVSS 7.8EPSS 0,21%Aucun correctif publié

    vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint

    In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang: 1. Use-after-free when no tpgs are found: This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do: vhost_vq_set_backend(vq, vs_tpg); ... kfree(vs

    Publication Mise à jour
  5. CVE-2025-22079

    Élevée · CVSS 7.8EPSS 0,25%Aucun correctif publié

    ocfs2: validate l_tree_depth to avoid out-of-bounds access

    In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate l_tree_depth to avoid out-of-bounds access The l_tree_depth field is 16-bit (__le16), but the actual maximum depth is limited to OCFS2_MAX_PATH_DEPTH. Add a check to prevent out-of-bounds access if l_tree_depth has an invalid value, which may occur when reading from a corrupted mounted disk [1].

    Publication Mise à jour
  6. CVE-2025-22073

    Moyenne · CVSS 5.5EPSS 0,23%Aucun correctif publié

    spufs: fix a leak on spufs_new_file() failure

    In the Linux kernel, the following vulnerability has been resolved: spufs: fix a leak on spufs_new_file() failure It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.

    Publication Mise à jour
  7. CVE-2025-22072

    Élevée · CVSS 7.8EPSS 0,21%Aucun correctif publié

    spufs: fix gang directory lifetimes

    In the Linux kernel, the following vulnerability has been resolved: spufs: fix gang directory lifetimes prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak. Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as

    Publication Mise à jour
  8. CVE-2025-22071

    Moyenne · CVSS 5.5EPSS 0,24%Aucun correctif publié

    spufs: fix a leak in spufs_create_context()

    In the Linux kernel, the following vulnerability has been resolved: spufs: fix a leak in spufs_create_context() Leak fixes back in 2008 missed one case - if we are trying to set affinity and spufs_mkdir() fails, we need to drop the reference to neighbor.

    Publication Mise à jour
  9. CVE-2025-22063

    Moyenne · CVSS 5.5EPSS 0,3%Aucun correctif publié

    netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets

    In the Linux kernel, the following vulnerability has been resolved: netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference. This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before access

    Publication Mise à jour
  10. CVE-2025-22060

    Moyenne · CVSS 4.7EPSS 0,16%Aucun correctif publié

    net: mvpp2: Prevent parser TCAM memory corruption

    In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: Prevent parser TCAM memory corruption Protect the parser TCAM/SRAM memory, and the cached (shadow) SRAM information, from concurrent modifications. Both the TCAM and SRAM tables are indirectly accessed by configuring an index register that selects the row to read or write to. This means that operations must be atomic in order to, e.g., avoid spreading writes across multiple rows. Since the shadow SRAM array is used to find free rows in the hardware table, it must also be protected in order to avoid TOCTOU errors where multiple cores allocate the same row. This

    Publication Mise à jour
  11. CVE-2025-22058

    Moyenne · CVSS 5.7EPSS 0,23%Aucun correctif publié

    udp: Fix memory accounting leak.

    In the Linux kernel, the following vulnerability has been resolved: udp: Fix memory accounting leak. Matt Dowling reported a weird UDP memory usage issue. Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops. We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,2

    Publication Mise à jour
  12. CVE-2025-22057

    Élevée · CVSS 7.8EPSS 0,21%Aucun correctif publié

    net: decrease cached dst counters in dst_release

    In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_de

    Publication Mise à jour
  13. CVE-2025-22053

    Moyenne · CVSS 5.5EPSS 0,15%Aucun correctif publié

    net: ibmveth: make veth_pool_store stop hanging

    In the Linux kernel, the following vulnerability has been resolved: net: ibmveth: make veth_pool_store stop hanging v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable. Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this easily with a little shell script. This causes a hang. I configured LOCKDEP, compiled ibmveth.c with DE

    Publication Mise à jour
  14. CVE-2025-22028

    Moyenne · CVSS 5.5EPSS 0,2%Aucun correctif publié

    media: vimc: skip .s_stream() for stopped entities

    In the Linux kernel, the following vulnerability has been resolved: media: vimc: skip .s_stream() for stopped entities Syzbot reported [1] a warning prompted by a check in call_s_stream() that checks whether .s_stream() operation is warranted for unstarted or stopped subdevs. Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that entities skip a call to .s_stream() unless they have been previously properly started. [1] Syzbot report: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460 Modules linked in:

    Publication Mise à jour
  15. CVE-2025-22027

    Moyenne · CVSS 4.7EPSS 0,17%Aucun correctif publié

    media: streamzap: fix race between device disconnection and urb callback

    In the Linux kernel, the following vulnerability has been resolved: media: streamzap: fix race between device disconnection and urb callback Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_device() is called before usb_kill_urb(). The dev->raw pointer is freed and set to NULL in rc_unregister_device(), and only after that usb_ki

    Publication Mise à jour
  16. CVE-2025-22025

    Élevée · CVSS 7.5EPSS 0,58%Aucun correctif publié

    nfsd: put dl_stid if fail to queue dl_recall

    In the Linux kernel, the following vulnerability has been resolved: nfsd: put dl_stid if fail to queue dl_recall Before calling nfsd4_run_cb to queue dl_recall to the callback_wq, we increment the reference count of dl_stid. We expect that after the corresponding work_struct is processed, the reference count of dl_stid will be decremented through the callback function nfsd4_cb_recall_release. However, if the call to nfsd4_run_cb fails, the incremented reference count of dl_stid will not be decremented correspondingly, leading to the following nfs4_stid leak: unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies

    Publication Mise à jour
  17. CVE-2024-58095

    Moyenne · CVSS 5.5EPSS 0,2%Aucun correctif publié

    jfs: add check read-only before txBeginAnon() call

    In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before txBeginAnon() call Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299

    Publication Mise à jour
  18. CVE-2024-58094

    Élevée · CVSS 7.8EPSS 0,23%Aucun correctif publié

    jfs: add check read-only before truncation in jfs_truncate_nolock()

    In the Linux kernel, the following vulnerability has been resolved: jfs: add check read-only before truncation in jfs_truncate_nolock() Added a check for "read-only" mode in the `jfs_truncate_nolock` function to avoid errors related to writing to a read-only filesystem. Call stack: block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL) If the `isReadOnly(ip)` condition is triggered in `jfs_truncate_nolock`, the function execution will stop, and no further data modification will occur. Instead, the `x

    Publication Mise à jour
  19. CVE-2025-22022

    Élevée · CVSS 7.8EPSS 0,2%Aucun correctif publié

    usb: xhci: Apply the link chain quirk on NEC isoc endpoints

    In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Apply the link chain quirk on NEC isoc endpoints Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment: [ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000

    Publication Mise à jour
  20. CVE-2025-22021

    Critique · CVSS 10EPSS 0,47%Aucun correctif publié

    netfilter: socket: Lookup orig tuple for IPv6 SNAT

    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

    Publication Mise à jour

Vérifiez votre serveur

Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.

Vérifiez votre serveur →