p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux · Page n° 166

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 4217

  1. CVE-2024-35811

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

    wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach

    In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brc

    Publication Mise à jour
  2. CVE-2024-35809

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

    PCI/PM: Drain runtime-idle callbacks before driver removal

    In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is cal

    Publication Mise à jour
  3. CVE-2024-35808

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

    md/dm-raid: don't call md_reap_sync_thread() directly

    In the Linux kernel, the following vulnerability has been resolved: md/dm-raid: don't call md_reap_sync_thread() directly Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'. However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock"). Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.

    Publication Mise à jour
  4. CVE-2024-35807

    Moyenne · CVSS 6.8EPSS 0,27%Aucun correctif publié

    ext4: fix corruption during on-line resize

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix corruption during on-line resize We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/<some_dev> # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode

    Publication Mise à jour
  5. CVE-2024-35805

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

    dm snapshot: fix lockup in dm_exception_table_exit

    In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.

    Publication Mise à jour
  6. CVE-2024-35803

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

    x86/efistub: Call mixed mode boot services on the firmware's stack

    In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the bo

    Publication Mise à jour
  7. CVE-2024-35784

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

    btrfs: fix deadlock with fiemap and extent locking

    In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock

    Publication Mise à jour
  8. CVE-2024-27436

    Moyenne · CVSS 5.3EPSS 0,62%Aucun correctif publié

    ALSA: usb-audio: Stop parsing channels bits when all channels are found.

    In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Stop parsing channels bits when all channels are found. If a usb audio device sets more bits than the amount of channels it could write outside of the map array.

    Publication Mise à jour
  9. CVE-2024-27415

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

    netfilter: bridge: confirm multicast packets before passing them up the stack

    In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: confirm multicast packets before passing them up the stack conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge no

    Publication Mise à jour
  10. CVE-2024-27410

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

    wifi: nl80211: reject iftype change with mesh ID change

    In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject iftype change with mesh ID change It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallo

    Publication Mise à jour
  11. CVE-2024-27405

    Élevée · CVSS 7.5EPSS 1,3%Aucun correctif publié

    usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

    In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Add

    Publication Mise à jour
  12. CVE-2024-27402

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

    phonet/pep: fix racy skb_queue_empty() use

    In the Linux kernel, the following vulnerability has been resolved: phonet/pep: fix racy skb_queue_empty() use The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.

    Publication Mise à jour
  13. CVE-2024-27401

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

    firewire: nosy: ensure user_length is taken into account when fetching packet contents

    In the Linux kernel, the following vulnerability has been resolved: firewire: nosy: ensure user_length is taken into account when fetching packet contents Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.

    Publication Mise à jour
  14. CVE-2024-27399

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

    Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below: [ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308

    Publication Mise à jour
  15. CVE-2021-34981

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

    Linux Kernel Bluetooth CMTP Module Double Free Privilege Escalation Vulnerability

    Linux Kernel Bluetooth CMTP Module Double Free Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the CMTP module. The issue results from the lack of validating the existence of an object prior to performing further free operations on the object. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the kernel. Was ZDI-CAN-11977.

    Publication Mise à jour
  16. CVE-2022-48702

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

    ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()

    In the Linux kernel, the following vulnerability has been resolved: ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc() The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around. This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur. This was initially discovered using PipeWire, however it can be reproduced by callin

    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 →