p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-ibm-5.15 · Page n° 74

Vulnérabilité publiée pour linux-ibm-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 : 2543

  1. CVE-2024-42124

    Moyenne · CVSS 5.5EPSS 0,26%Correctif disponible

    scsi: qedf: Make qedf_execute_tmf() non-preemptible

    In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Make qedf_execute_tmf() non-preemptible Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  2. CVE-2024-42121

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

    drm/amd/display: Check index msg_id before read or write

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index msg_id before read or write [WHAT] msg_id is used as an array index and it cannot be a negative value, and therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1). [HOW] Check whether msg_id is valid before reading and setting. This fixes 4 OVERRUN issues reported by Coverity.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  3. CVE-2024-42120

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

    drm/amd/display: Check pipe offset before setting vblank

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check pipe offset before setting vblank pipe_ctx has a size of MAX_PIPES so checking its index before accessing the array. This fixes an OVERRUN issue reported by Coverity.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  4. CVE-2024-42119

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

    drm/amd/display: Skip finding free audio for unknown engine_id

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip finding free audio for unknown engine_id [WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio. [HOW] Skip and return NULL. This fixes 2 OVERRUN issues reported by Coverity.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  5. CVE-2024-42115

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

    jffs2: Fix potential illegal address access in jffs2_free_inode

    In the Linux kernel, the following vulnerability has been resolved: jffs2: Fix potential illegal address access in jffs2_free_inode During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  6. CVE-2024-42114

    Moyenne · CVSS 6.8EPSS 0,18%Correctif disponible

    wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values

    In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31. We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM") watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x1

    • Mettez à jour vers 5.15.0-1065.68~20.04.1
    Publication Mise à jour
  7. CVE-2024-42109

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

    netfilter: nf_tables: unconditionally flush pending work before notifier

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally flush pending work before notifier syzbot reports: KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45 [..] Workqueue: events nf_tables_trans_destroy_work Call Trace: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline] nft_commit_release net/netfilter/nf_tables_api.c:9530

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  8. CVE-2024-42106

    Moyenne · CVSS 5.5EPSS 0,27%Correctif disponible

    inet_diag: Initialize pad field in struct inet_diag_req_v2

    In the Linux kernel, the following vulnerability has been resolved: inet_diag: Initialize pad field in struct inet_diag_req_v2 KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  9. CVE-2024-42105

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

    nilfs2: fix inode number range checks

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix inode number range checks Patch series "nilfs2: fix potential issues related to reserved inodes". This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value. This patch (of 3): In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inod

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  10. CVE-2024-42104

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

    nilfs2: add missing check for inode numbers on directory entries

    In the Linux kernel, the following vulnerability has been resolved: nilfs2: add missing check for inode numbers on directory entries Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should no

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  11. CVE-2024-42102

    Moyenne · CVSS 4.7EPSS 0,26%Correctif disponible

    Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"

    In the Linux kernel, the following vulnerability has been resolved: Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again" Patch series "mm: Avoid possible overflows in dirty throttling". Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details). This patch (of 2): This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78. The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is a

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  12. CVE-2024-42101

    Moyenne · CVSS 5.7EPSS 0,26%Correctif disponible

    drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes

    In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  13. CVE-2024-42098

    Moyenne · CVSS 5.5EPSS 0,21%Correctif disponible

    crypto: ecdh - explicitly zeroize private_key

    In the Linux kernel, the following vulnerability has been resolved: crypto: ecdh - explicitly zeroize private_key private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first. Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey fai

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  14. CVE-2024-42097

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

    ALSA: emux: improve patch ioctl data validation

    In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  15. CVE-2024-42096

    Moyenne · CVSS 5.5EPSS 0,24%Correctif disponible

    x86: stop playing stack games in profile_pc()

    In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layo

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  16. CVE-2024-42095

    Moyenne · CVSS 5.5EPSS 0,21%Correctif disponible

    serial: 8250_omap: Implementation of Errata i2310

    In the Linux kernel, the following vulnerability has been resolved: serial: 8250_omap: Implementation of Errata i2310 As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution. [0] https://www.ti.com/lit/pdf/sprz536 page 23

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  17. CVE-2024-42094

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

    net/iucv: Avoid explicit cpumask var allocation on stack

    In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  18. CVE-2024-42093

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

    net/dpaa2: Avoid explicit cpumask var allocation on stack

    In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  19. CVE-2024-42092

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

    gpio: davinci: Validate the obtained number of IRQs

    In the Linux kernel, the following vulnerability has been resolved: gpio: davinci: Validate the obtained number of IRQs Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE.

    • Mettez à jour vers 5.15.0-1062.65~20.04.1
    Publication Mise à jour
  20. CVE-2024-42090

    Moyenne · CVSS 5.5EPSS 0,19%Correctif disponible

    pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER

    In the Linux kernel, the following vulnerability has been resolved: pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAS

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