p PatchFirst

PatchFirst · Latest vulnerabilities

linux-nvidia-tegra-5.15 vulnerabilities · Page 110

Vulnerabilities published for linux-nvidia-tegra-5.15 in the last 30 days: 0. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Clear filters

Vulnerabilities: 2668

  1. CVE-2024-26840

    Medium · CVSS 5.5EPSS 0.28%Fix available

    cachefiles: fix memory leak in cachefiles_add_cache()

    In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix memory leak in cachefiles_add_cache() The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 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 (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  2. CVE-2024-26839

    Medium · CVSS 5.5EPSS 0.24%Fix available

    IB/hfi1: Fix a memleak in init_credit_return

    In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  3. CVE-2024-26838

    High · CVSS 7.8EPSS 0.24%Fix available

    RDMA/irdma: Fix KASAN issue with tasklet

    In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix KASAN issue with tasklet KASAN testing revealed the following issue assocated with freeing an IRQ. [50006.466686] Call Trace: [50006.466691] <IRQ> [50006.489538] dump_stack+0x5c/0x80 [50006.493475] print_address_description.constprop.6+0x1a/0x150 [50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.511644] kasan_report.cold.11+0x7f/0x118 [50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.528232] irdma_process_c

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  4. CVE-2024-26835

    Medium · CVSS 5.5EPSS 0.23%Fix available

    netfilter: nf_tables: set dormant flag on hook register failure

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: set dormant flag on hook register failure We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core.

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  5. CVE-2024-26833

    Medium · CVSS 5.5EPSS 0.23%Fix available

    drm/amd/display: Fix memory leak in dm_sw_fini()

    In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak in dm_sw_fini() After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak: unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 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 (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  6. CVE-2024-26830

    High · CVSS 8.4EPSS 0.23%Fix available

    i40e: Do not allow untrusted VF to remove administratively set MAC

    In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link

    • Update to 5.15.0-1030.30~20.04.1
    Published Updated
  7. CVE-2024-26828

    Critical · CVSS 9.4EPSS 0.75%Fix available

    cifs: fix underflow in parse_server_interfaces()

    In the Linux kernel, the following vulnerability has been resolved: cifs: fix underflow in parse_server_interfaces() In this loop, we step through the buffer and after each item we check if the size_left is greater than the minimum size we need. However, the problem is that "bytes_left" is type ssize_t while sizeof() is type size_t. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  8. CVE-2024-26826

    High · CVSS 7.5EPSS 0.65%Fix available

    mptcp: fix data re-injection from stale subflow

    In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data re-injection from stale subflow When the MPTCP PM detects that a subflow is stale, all the packet scheduler must re-inject all the mptcp-level unacked data. To avoid acquiring unneeded locks, it first try to check if any unacked data is present at all in the RTX queue, but such check is currently broken, as it uses TCP-specific helper on an MPTCP socket. Funnily enough fuzzers and static checkers are happy, as the accessed memory still belongs to the mptcp_sock struct, and even from a functional perspective the recovery completed successfully, as the short-

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  9. CVE-2024-26825

    Medium · CVSS 5.5EPSS 0.24%Fix available

    nfc: nci: free rx_data_reassembly skb on NCI device cleanup

    In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free rx_data_reassembly skb on NCI device cleanup rx_data_reassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak. As by design the rx_data_reassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup. Found by Linux Veri

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  10. CVE-2024-26822

    High · CVSS 8.7EPSS 0.23%Fix available

    smb: client: set correct id, uid and cruid for multiuser automounts

    In the Linux kernel, the following vulnerability has been resolved: smb: client: set correct id, uid and cruid for multiuser automounts When uid, gid and cruid are not specified, we need to dynamically set them into the filesystem context used for automounting otherwise they'll end up reusing the values from the parent mount.

    • Update to 5.15.0-1032.32~20.04.1
    Published Updated
  11. CVE-2023-52643

    Medium · CVSS 5.5EPSS 0.22%Fix available

    iio: core: fix memleak in iio_device_register_sysfs

    In the Linux kernel, the following vulnerability has been resolved: iio: core: fix memleak in iio_device_register_sysfs When iio_device_register_sysfs_group() fails, we should free iio_dev_opaque->chan_attr_group.attrs to prevent potential memleak.

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  12. CVE-2024-24856

    Medium · CVSS 5.3EPSS 0.17%Fix available

    NULL pointer deference in acpi_db_convert_to_package of Linux acpi module

    The memory allocation function ACPI_ALLOCATE_ZEROED does not guarantee a successful allocation, but the subsequent code directly dereferences the pointer that receives it, which may lead to null pointer dereference. To fix this issue, a null pointer check should be added. If it is null, return exception code AE_NO_MEMORY.

    • Update to 5.15.0-1017.17~20.04.1
    Published Updated
  13. CVE-2024-26817

    Medium · CVSS 5.5EPSS 0.76%Fix available

    amdkfd: use calloc instead of kzalloc to avoid integer overflow

    In the Linux kernel, the following vulnerability has been resolved: amdkfd: use calloc instead of kzalloc to avoid integer overflow This uses calloc instead of doing the multiplication which might overflow.

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  14. CVE-2024-26816

    Medium · CVSS 5.5EPSS 0.31%Fix available

    x86, relocs: Ignore relocations in .notes section

    In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. Th

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  15. CVE-2024-26811

    Critical · CVSS 9.8EPSS 0.79%Fix available

    ksmbd: validate payload size in ipc response

    In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate payload size in ipc response If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload.

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  16. CVE-2024-27437

    Medium · CVSS 5.5EPSS 0.24%Fix available

    vfio/pci: Disable auto-enable of exclusive INTx IRQ

    In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is ne

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  17. CVE-2024-26814

    Medium · CVSS 5.5EPSS 0.22%Fix available

    vfio/fsl-mc: Block calling interrupt handler without trigger

    In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it suppo

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
  18. CVE-2024-26813

    Medium · CVSS 5.5EPSS 0.23%Fix available

    vfio/platform: Create persistent IRQ handlers

    In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mu

    • Update to 5.15.0-1027.27~20.04.1
    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →