p PatchFirst

PatchFirst · Vulnerabilidades recientes

Vulnerabilidades de linux-oracle-5.15 · Página 125

Vulnerabilidades publicadas para linux-oracle-5.15 en los últimos 30 días: 0. Incluidas en el catálogo KEV: 0.

RSS ↗ JSON ↗
Filtrar vulnerabilidades
Borrar filtros

Vulnerabilidades: 4250

  1. CVE-2024-50033

    Crítica · CVSS 9.8EPSS 0,78%Corrección disponible

    slip: make slhc_remember() more robust against malicious packets

    In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x3

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  2. CVE-2024-50031

    Alta · CVSS 7.8EPSS 0,24%Corrección disponible

    drm/v3d: Stop the active perfmon before being destroyed

    In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] I

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  3. CVE-2024-50024

    Alta · CVSS 7.3EPSS 0,28%Corrección disponible

    net: Fix an unsafe loop on the list

    In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  4. CVE-2024-50019

    Media · CVSS 5.5EPSS 0,24%Corrección disponible

    kthread: unpark only parked kthread

    In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bi

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  5. CVE-2024-50015

    Media · CVSS 5.5EPSS 0,24%Corrección disponible

    ext4: dax: fix overflowing extents beyond inode size when partially writing

    In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(wri

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  6. CVE-2024-50013

    Media · CVSS 5.5EPSS 0,22%Corrección disponible

    exfat: fix memory leak in exfat_load_bitmap()

    In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  7. CVE-2024-50010

    Media · CVSS 4.7EPSS 0,22%Corrección disponible

    exec: don't WARN for racy path_noexec check

    In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move S_ISREG() check earlier") 0fd338b2d2cd ("exec: move path_noexec() check earlier") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can not

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1075.81~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  8. CVE-2024-50008

    Media · CVSS 5.5EPSS 0,25%Corrección disponible

    wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()

    In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan->tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwi

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  9. CVE-2024-50007

    Alta · CVSS 7.8EPSS 0,25%Corrección disponible

    ALSA: asihpi: Fix potential OOB array access

    In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  10. CVE-2024-50006

    Media · CVSS 4.7EPSS 0,19%Corrección disponible

    ext4: fix i_data_sem unlock order in ext4_ind_migrate()

    In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  11. CVE-2024-50003

    Media · CVSS 5.7EPSS 0,22%Corrección disponible

    drm/amd/display: Fix system hang while resume with TBT monitor

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  14. CVE-2024-50002

    Media · CVSS 5.5EPSS 0,24%Corrección disponible

    static_call: Handle module init failure correctly in static_call_del_module()

    In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added stat

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  15. CVE-2024-50001

    Alta · CVSS 7.8EPSS 0,33%Corrección disponible

    net/mlx5: Fix error path in multi-packet WQE transmit

    In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  16. CVE-2024-50000

    Media · CVSS 5.5EPSS 0,24%Corrección disponible

    net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()

    In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  17. CVE-2024-49998

    Media · CVSS 4.7EPSS 0,19%Corrección disponible

    net: dsa: improve shutdown sequence

    In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata(

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1077.83~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  18. CVE-2024-49997

    Alta · CVSS 7.5EPSS 1,06%Corrección disponible

    net: ethernet: lantiq_etop: fix memory disclosure

    In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  19. CVE-2024-49996

    Crítica · CVSS 9.4EPSS 0,78%Corrección disponible

    cifs: Fix buffer overflow when parsing NFS reparse points

    In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to pr

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1077.83~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

  20. CVE-2024-49985

    Media · CVSS 5.7EPSS 0,2%Corrección disponible

    i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume

    In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which

    linux-oracle-5.15Sistemas operativos
    • Actualiza a 5.15.0-1071.77~20.04.1
    Publicación Actualización
    Aviso original 1 ↗Aviso original 2 ↗Aviso original 3 ↗

Comprueba tu servidor

Compara tu pila y las versiones instaladas con las bases actuales de vulnerabilidades.

Comprueba tu servidor →