p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-aws-fips · Page n° 191

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

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 8218

  1. CVE-2023-53722

    Non évaluéeEPSS 0,21%Aucun correctif publié

    md: raid1: fix potential OOB in raid1_remove_disk()

    In the Linux kernel, the following vulnerability has been resolved: md: raid1: fix potential OOB in raid1_remove_disk() If rddev->raid_disk is greater than mddev->raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows: 1) commit d17f744e883b ("md-raid10: fix KASAN warning") 2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk") Fix this bug by checking whether the "number" variable is valid.

    Publication Mise à jour
  2. CVE-2023-53719

    Non évaluéeEPSS 0,21%Aucun correctif publié

    serial: arc_uart: fix of_iomap leak in `arc_serial_probe`

    In the Linux kernel, the following vulnerability has been resolved: serial: arc_uart: fix of_iomap leak in `arc_serial_probe` Smatch reports: drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn: 'port->membase' from of_iomap() not released on lines: 631. In arc_serial_probe(), if uart_add_one_port() fails, port->membase is not released, which would cause a resource leak. To fix this, I replace of_iomap with devm_platform_ioremap_resource.

    Publication Mise à jour
  3. CVE-2023-53718

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

    ring-buffer: Do not swap cpu_buffer during resize process

    In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not swap cpu_buffer during resize process When ring_buffer_swap_cpu was called during resize process, the cpu buffer was swapped in the middle, resulting in incorrect state. Continuing to run in the wrong state will result in oops. This issue can be easily reproduced using the following two scripts: /tmp # cat test1.sh //#! /bin/sh for i in `seq 0 100000` do echo 2000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 echo 5000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 done /tmp # cat test2.sh //#! /bin/sh fo

    Publication Mise à jour
  4. CVE-2023-53717

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

    wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()

    In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback() Fix a stack-out-of-bounds write that occurs in a WMI response callback function that is called after a timeout occurs in ath9k_wmi_cmd(). The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer that could no longer be valid when a timeout occurs. Set wmi->last_seq_id to 0 when a timeout occurred. Found by a modified version of syzkaller. BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx Write of size 4 Call Trace: memcpy ath9k_wmi_ctrl_rx ath9k_htc_rx_msg ath9k_hif_usb_reg_in

    Publication Mise à jour
  5. CVE-2023-53715

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

    wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex

    In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex Apparently the hex passphrase mechanism does not work on newer chips/firmware (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid the hexification. OpenBSD has been doing it like this from the beginning, so this should work on all chips. Also clear the structure before setting the PMK. This was leaking uninitialized stack contents to the device.

    Publication Mise à jour
  6. CVE-2023-53712

    Non évaluéeEPSS 0,21%Aucun correctif publié

    ARM: 9317/1: kexec: Make smp stop calls asynchronous

    In the Linux kernel, the following vulnerability has been resolved: ARM: 9317/1: kexec: Make smp stop calls asynchronous If a panic is triggered by a hrtimer interrupt all online cpus will be notified and set offline. But as highlighted by commit 19dbdcb8039c ("smp: Warn on function calls from softirq context") this call should not be made synchronous with disabled interrupts: softdog: Initiating panic Kernel panic - not syncing: Software Watchdog Timer expired WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond unwind_backtrace: show_stack dump_stack_lvl __warn warn_slowpath_fmt smp_call_f

    Publication Mise à jour
  7. CVE-2023-53707

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

    drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1

    In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later.

    Publication Mise à jour
  8. CVE-2023-53705

    Élevée · CVSS 8.2EPSS 0,56%Aucun correctif publié

    ipv6: Fix out-of-bounds access in ipv6_find_tlv()

    In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix out-of-bounds access in ipv6_find_tlv() optlen is fetched without checking whether there is more than one byte to parse. It can lead to out-of-bounds access. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.

    Publication Mise à jour
  9. CVE-2023-53699

    Non évaluéeEPSS 0,21%Aucun correctif publié

    riscv: move memblock_allow_resize() after linear mapping is ready

    In the Linux kernel, the following vulnerability has been resolved: riscv: move memblock_allow_resize() after linear mapping is ready The initial memblock metadata is accessed from kernel image mapping. The regions arrays need to "reallocated" from memblock and accessed through linear mapping to cover more memblock regions. So the resizing should not be allowed until linear mapping is ready. Note that there are memblock allocations when building linear mapping. This patch is similar to 24cc61d8cb5a ("arm64: memblock: don't permit memblock resizing until linear mapping is up"). In following log, many memblock regions are reserved before cr

    Publication Mise à jour
  10. CVE-2023-53696

    Non évaluéeEPSS 0,21%Aucun correctif publié

    scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()

    In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in qla2x00_probe_one() There is a memory leak reported by kmemleak: unreferenced object 0xffffc900003f0000 (size 12288): comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_node+0xbd/0x150 [<000000005bb4dc34>] vmalloc+0x25/0x30 [<

    Publication Mise à jour
  11. CVE-2023-53695

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

    udf: Detect system inodes linked into directory hierarchy

    In the Linux kernel, the following vulnerability has been resolved: udf: Detect system inodes linked into directory hierarchy When UDF filesystem is corrupted, hidden system inodes can be linked into directory hierarchy which is an avenue for further serious corruption of the filesystem and kernel confusion as noticed by syzbot fuzzed images. Refuse to access system inodes linked into directory hierarchy and vice versa.

    Publication Mise à jour
  12. CVE-2022-50581

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

    hfs: fix OOB Read in __hfs_brec_find

    In the Linux kernel, the following vulnerability has been resolved: hfs: fix OOB Read in __hfs_brec_find Syzbot reported a OOB read bug: ================================================================== BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11 CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted 6.1.0-rc6-syzkaller-00308-g644e9524388a #0 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284

    Publication Mise à jour
  13. CVE-2022-50580

    Non évaluéeEPSS 0,21%Aucun correctif publié

    blk-throttle: prevent overflow while calculating wait time

    In the Linux kernel, the following vulnerability has been resolved: blk-throttle: prevent overflow while calculating wait time There is a problem found by code review in tg_with_in_bps_limit() that 'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem by calling mul_u64_u64_div_u64() instead.

    Publication Mise à jour
  14. CVE-2022-50578

    Faible · CVSS 2EPSS 0,24%Aucun correctif publié

    class: fix possible memory leak in __class_register()

    In the Linux kernel, the following vulnerability has been resolved: class: fix possible memory leak in __class_register() If class_add_groups() returns error, the 'cp->subsys' need be unregister, and the 'cp' need be freed. We can not call kset_unregister() here, because the 'cls' will be freed in callback function class_release() and it's also freed in caller's error path, it will cause double free. So fix this by calling kobject_del() and kfree_const(name) to cleanup kobject. Besides, call kfree() to free the 'cp'. Fault injection test can trigger this: unreferenced object 0xffff888102fa8190 (size 8): comm "modprobe", pid 502, jiffi

    Publication Mise à jour
  15. CVE-2022-50576

    Non évaluéeEPSS 0,25%Aucun correctif publié

    serial: pch: Fix PCI device refcount leak in pch_request_dma()

    In the Linux kernel, the following vulnerability has been resolved: serial: pch: Fix PCI device refcount leak in pch_request_dma() As comment of pci_get_slot() says, it returns a pci_device with its refcount increased. The caller must decrement the reference count by calling pci_dev_put(). Since 'dma_dev' is only used to filter the channel in filter(), we can call pci_dev_put() before exiting from pch_request_dma(). Add the missing pci_dev_put() for the normal and error path.

    Publication Mise à jour
  16. CVE-2022-50575

    Non évaluéeEPSS 0,22%Aucun correctif publié

    xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource()

    In the Linux kernel, the following vulnerability has been resolved: xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource() As 'kdata.num' is user-controlled data, if user tries to allocate memory larger than(>=) MAX_ORDER, then kcalloc() will fail, it creates a stack trace and messes up dmesg with a warning. Call trace: -> privcmd_ioctl --> privcmd_ioctl_mmap_resource Add __GFP_NOWARN in order to avoid too large allocation warning. This is detected by static analysis using smatch.

    Publication Mise à jour
  17. CVE-2022-50574

    Non évaluéeEPSS 0,22%Aucun correctif publié

    drm/omap: dss: Fix refcount leak bugs

    In the Linux kernel, the following vulnerability has been resolved: drm/omap: dss: Fix refcount leak bugs In dss_init_ports() and __dss_uninit_ports(), we should call of_node_put() for the reference returned by of_graph_get_port_by_id() in fail path or when it is not used anymore.

    Publication Mise à jour
  18. CVE-2022-50572

    Non évaluéeEPSS 0,22%Aucun correctif publié

    ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link()

    In the Linux kernel, the following vulnerability has been resolved: ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link() The of_get_next_child() returns a node with refcount incremented, and decrements the refcount of prev. So in the error path of the while loop, of_node_put() needs be called for cpu_ep.

    Publication Mise à jour
  19. CVE-2022-50569

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

    xfrm: Update ipcomp_scratches with NULL when freed

    In the Linux kernel, the following vulnerability has been resolved: xfrm: Update ipcomp_scratches with NULL when freed Currently if ipcomp_alloc_scratches() fails to allocate memory ipcomp_scratches holds obsolete address. So when we try to free the percpu scratches using ipcomp_free_scratches() it tries to vfree non existent vm area. Described below: static void * __percpu *ipcomp_alloc_scratches(void) { ... scratches = alloc_percpu(void *); if (!scratches) return NULL; ipcomp_scratches does not know about this allocation failure. Therefore holding the old obsolete address. ... } So when we

    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 →