p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-azure-5.15 · Page n° 200

Vulnérabilité publiée pour linux-azure-5.15 au cours des 30 derniers jours : 0. Dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 4525

  1. CVE-2023-52578

    Élevée · CVSS 7EPSS 0,19%Correctif disponible

    net: bridge: use DEV_STATS_INC()

    In the Linux kernel, the following vulnerability has been resolved: net: bridge: use DEV_STATS_INC() syzbot/KCSAN reported data-races in br_handle_frame_finish() [1] This function can run from multiple cpus without mutual exclusion. Adopt SMP safe DEV_STATS_INC() to update dev->stats fields. Handles updates to dev->stats.tx_dropped while we are at it. [1] BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK inclu

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  2. CVE-2023-52574

    Élevée · CVSS 7.8EPSS 0,25%Correctif disponible

    team: fix null-ptr-deref when team device type is changed

    In the Linux kernel, the following vulnerability has been resolved: team: fix null-ptr-deref when team device type is changed Get a null-ptr-deref bug as follows with reproducer [1]. BUG: kernel NULL pointer dereference, address: 0000000000000228 ... RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q] ... Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ? ip6_mtu+0x46/0x80 ip6_finish_

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  3. CVE-2023-52573

    Moyenne · CVSS 5.5EPSS 0,23%Correctif disponible

    net: rds: Fix possible NULL-pointer dereference

    In the Linux kernel, the following vulnerability has been resolved: net: rds: Fix possible NULL-pointer dereference In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists before dereferencing it as rdma_set_service_type() argument Found by Linux Verification Center (linuxtesting.org) with SVACE.

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  4. CVE-2023-52572

    Élevée · CVSS 7.8EPSS 0,23%Correctif disponible

    cifs: Fix UAF in cifs_demultiplex_thread()

    In the Linux kernel, the following vulnerability has been resolved: cifs: Fix UAF in cifs_demultiplex_thread() There is a UAF when xfstests on cifs: BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923 CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 </TASK> Allocated b

    • Mettez à jour vers 5.15.0-1078.87~20.04.1
    Publication Mise à jour
  5. CVE-2023-52567

    Moyenne · CVSS 5.5EPSS 0,24%Correctif disponible

    serial: 8250_port: Check IRQ data before use

    In the Linux kernel, the following vulnerability has been resolved: serial: 8250_port: Check IRQ data before use In case the leaf driver wants to use IRQ polling (irq = 0) and IIR register shows that an interrupt happened in the 8250 hardware the IRQ data can be NULL. In such a case we need to skip the wake event as we came to this path from the timer interrupt and quite likely system is already awake. Without this fix we have got an Oops: serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A ... BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:serial8250_handle_irq+0x7c/0x240

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  6. CVE-2023-52566

    Moyenne · CVSS 5.5EPSS 0,24%Correctif disponible

    nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools,

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  7. CVE-2023-52564

    Moyenne · CVSS 6.7EPSS 0,25%Correctif disponible

    Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"

    In the Linux kernel, the following vulnerability has been resolved: Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux" This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. The commit above is reverted as it did not solve the original issue. gsm_cleanup_mux() tries to free up the virtual ttys by calling gsm_dlci_release() for each available DLCI. There, dlci_put() is called to decrease the reference counter for the DLCI via tty_port_put() which finally calls gsm_dlci_free(). This already clears the pointer which is being checked in gsm_cleanup_mux() before calling gsm_dlci_release(). Therefore, it is not necessary to clear this point

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  8. CVE-2023-52559

    Moyenne · CVSS 5.5EPSS 0,22%Correctif disponible

    iommu/vt-d: Avoid memory allocation in iommu_suspend()

    In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid memory allocation in iommu_suspend() The iommu_suspend() syscore suspend callback is invoked with IRQ disabled. Allocating memory with the GFP_KERNEL flag may re-enable IRQs during the suspend callback, which can cause intermittent suspend/hibernation problems with the following kernel traces: Calling iommu_suspend+0x0/0x1d0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 ... CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 ... Call T

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  9. CVE-2023-52532

    Moyenne · CVSS 5.7EPSS 0,23%Correctif disponible

    net: mana: Fix TX CQE error handling

    In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging.

    • Mettez à jour vers 5.15.0-1078.87~20.04.1
    Publication Mise à jour
  10. CVE-2023-52531

    Élevée · CVSS 7.8EPSS 0,24%Correctif disponible

    wifi: iwlwifi: mvm: Fix a memory corruption issue

    In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct ieee80211_channel'. So only 1 element is allocated in this array. When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the 'channels' flex array. So this is fine. However,

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  11. CVE-2023-52530

    Élevée · CVSS 8.8EPSS 0,34%Correctif disponible

    wifi: mac80211: fix potential key use-after-free

    In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential key use-after-free When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gt

    • Mettez à jour vers 5.15.0-1064.73~20.04.1
    Publication Mise à jour
  12. CVE-2023-52529

    Moyenne · CVSS 6EPSS 0,23%Correctif disponible

    HID: sony: Fix a potential memory leak in sony_probe()

    In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be called.

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  13. CVE-2023-52528

    Moyenne · CVSS 5.5EPSS 0,24%Correctif disponible

    net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg

    In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  14. CVE-2023-52527

    Moyenne · CVSS 5.5EPSS 0,24%Correctif disponible

    ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()

    In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don't want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_outpu

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  15. CVE-2023-52524

    Élevée · CVSS 7.8EPSS 0,18%Correctif disponible

    net: nfc: llcp: Add lock when modifying device list

    In the Linux kernel, the following vulnerability has been resolved: net: nfc: llcp: Add lock when modifying device list The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered.

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  16. CVE-2023-52523

    Élevée · CVSS 7.8EPSS 0,24%Correctif disponible

    bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets

    In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages sent from one TCP socket (s1) to actually egress from another TCP socket (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT case tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_app_limited(s2) // expects tcp_sock tcp_sendmsg_locked(s2) // ditto There is a hard-coded assumption in the call-chain, that the egress socket (s2) is a TCP socket. How

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  17. CVE-2023-52522

    Élevée · CVSS 8.8EPSS 0,34%Correctif disponible

    net: fix possible store tearing in neigh_periodic_work()

    In the Linux kernel, the following vulnerability has been resolved: net: fix possible store tearing in neigh_periodic_work() While looking at a related syzbot report involving neigh_periodic_work(), I found that I forgot to add an annotation when deleting an RCU protected item from a list. Readers use rcu_deference(*np), we need to use either rcu_assign_pointer() or WRITE_ONCE() on writer side to prevent store tearing. I use rcu_assign_pointer() to have lockdep support, this was the choice made in neigh_flush_dev().

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  18. CVE-2023-52520

    Moyenne · CVSS 5.5EPSS 0,24%Correctif disponible

    platform/x86: think-lmi: Fix reference leak

    In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver. Compile-tested only.

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    Publication Mise à jour
  19. CVE-2023-52519

    Élevée · CVSS 7.1EPSS 0,24%Correctif disponible

    HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit

    In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable it in resume function to keep the next wakeup capability. But this BIOS clearing of wakeup bit doesn't decrement internal

    • Mettez à jour vers 5.15.0-1056.64~20.04.1
    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 →