p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-azure-fips · Page n° 193

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

RSS ↗ JSON ↗
Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 7118

  1. CVE-2025-38174

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

    thunderbolt: Do not double dequeue a configuration request

    In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Do not double dequeue a configuration request Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: <TASK> ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be sc

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  3. CVE-2025-38163

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

    f2fs: fix to do sanity check on sbi->total_valid_block_count

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on sbi->total_valid_block_count syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  4. CVE-2025-38161

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

    RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction

    In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_uc

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  5. CVE-2025-38157

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

    wifi: ath9k_htc: Abort software beacon handling if disabled

    In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Abort software beacon handling if disabled A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled.

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  6. CVE-2025-38147

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

    calipso: Don't call calipso functions for AF_INET sk.

    In the Linux kernel, the following vulnerability has been resolved: calipso: Don't call calipso functions for AF_INET sk. syzkaller reported a null-ptr-deref in txopt_get(). [0] The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo, so struct ipv6_pinfo was NULL there. However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6 is always set in inet6_create(), meaning the socket was not IPv6 one. The root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct sockaddr.sa_family, which is passed from userspace. However, netlbl_conn_setattr() does not check if the

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  7. CVE-2025-38136

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

    usb: renesas_usbhs: Reorder clock handling and power management in probe

    In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Reorder clock handling and power management in probe Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access befor

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  8. CVE-2025-38129

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

    page_pool: Fix use-after-free in page_pool_recycle_in_ring

    In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix use-after-free in page_pool_recycle_in_ring syzbot reported a uaf in page_pool_recycle_in_ring: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943 CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_descrip

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  9. CVE-2025-38126

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

    net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping

    In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping The stmmac platform drivers that do not open-code the clk_ptp_rate value after having retrieved the default one from the device-tree can end up with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace fro

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  10. CVE-2025-38119

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

    scsi: core: ufs: Fix a hang in the error handler

    In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before. Backtrace: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_co

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  11. CVE-2025-38117

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

    Bluetooth: MGMT: Protect mgmt_pending list with its own lock

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Protect mgmt_pending list with its own lock This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Ca

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  12. CVE-2025-38105

    Élevée · CVSS 7EPSS 0,19%Aucun correctif publié

    ALSA: usb-audio: Kill timer properly at removal

    In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback wi

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  13. CVE-2025-38103

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

    HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()

    In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates t

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  14. CVE-2025-38102

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

    VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify

    In the Linux kernel, the following vulnerability has been resolved: VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  15. CVE-2025-38096

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

    wifi: iwlwifi: don't warn when if there is a FW error

    In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: don't warn when if there is a FW error iwl_trans_reclaim is warning if it is called when the FW is not alive. But if it is called when there is a pending restart, i.e. after a FW error, there is no need to warn, instead - return silently.

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  16. CVE-2025-38094

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

    net: cadence: macb: Fix a possible deadlock in macb_halt_tx.

    In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  17. CVE-2025-38090

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

    drivers/rapidio/rio_cm.c: prevent possible heap overwrite

    In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  18. CVE-2025-38086

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

    net: ch9200: fix uninitialised access during mii_nway_restart

    In the Linux kernel, the following vulnerability has been resolved: net: ch9200: fix uninitialised access during mii_nway_restart In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  19. CVE-2025-38085

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

    mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

    In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI throug

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

  20. CVE-2025-38084

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

    mm/hugetlb: unshare page tables during VMA split, not before

    In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the r

    linux-azure-fipsSystèmes d’exploitation
    Publication Mise à jour
    Avis original 1 ↗Avis original 2 ↗Avis original 3 ↗

Vérifiez votre serveur

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

Vérifiez votre serveur →