p PatchFirst

PatchFirst · Latest vulnerabilities

linux-nvidia-tegra-5.15 vulnerabilities · Page 99

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

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 2668

  1. CVE-2023-52699

    Medium · CVSS 5.3EPSS 0.97%Fix available

    sysv: don't call sb_bread() with pointers_lock held

    In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2024-35915

    High · CVSS 8.8EPSS 0.32%Fix available

    nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet

    In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes.

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2024-35912

    Medium · CVSS 5.5EPSS 0.21%Fix available

    wifi: iwlwifi: mvm: rfi: fix potential response leaks

    In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential response leaks If the rx payload length check fails, or if kmemdup() fails, we still need to free the command response. Fix that.

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2024-35910

    High · CVSS 7.8EPSS 0.26%Fix available

    tcp: properly terminate timers for kernel sockets

    In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sock

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2024-35907

    Medium · CVSS 5.5EPSS 0.23%Fix available

    mlxbf_gige: call request_irq() after NAPI initialized

    In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: call request_irq() after NAPI initialized The mlxbf_gige driver encounters a NULL pointer exception in mlxbf_gige_open() when kdump is enabled. The sequence to reproduce the exception is as follows: a) enable kdump b) trigger kdump via "echo c > /proc/sysrq-trigger" c) kdump kernel executes d) kdump kernel loads mlxbf_gige module e) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought up f) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2024-35904

    Medium · CVSS 5.5EPSS 0.23%Fix available

    selinux: avoid dereference of garbage after mount failure

    In the Linux kernel, the following vulnerability has been resolved: selinux: avoid dereference of garbage after mount failure In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer. While on it drop the never read static variable selinuxfs_mount.

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1032.32~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2024-35900

    Medium · CVSS 6.8EPSS 0.23%Fix available

    netfilter: nf_tables: reject new basechain after table flag update

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject new basechain after table flag update When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new). The following configuration allows for an inconsistent state: add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; } which triggers the following warning when trying to unregister chain w which is already unregistered. [ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2024-35899

    High · CVSS 7.3EPSS 0.2%Fix available

    netfilter: nf_tables: flush pending destroy work before exit_net release

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: flush pending destroy work before exit_net release Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2024-35898

    High · CVSS 7EPSS 0.2%Fix available

    netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to pro

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  10. CVE-2024-35897

    High · CVSS 7.8EPSS 0.25%Fix available

    netfilter: nf_tables: discard table flag update with pending basechain deletion

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: discard table flag update with pending basechain deletion Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2024-35896

    High · CVSS 7.1EPSS 0.23%Fix available

    netfilter: validate user input for expected length

    In the Linux kernel, the following vulnerability has been resolved: netfilter: validate user input for expected length I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt") setsockopt() @optlen argument should be taken into account before copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bou

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  12. CVE-2024-35895

    Medium · CVSS 5.6EPSS 0.18%Fix available

    bpf, sockmap: Prevent lock inversion deadlock in map delete elem

    In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Prevent lock inversion deadlock in map delete elem syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable();

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  13. CVE-2024-35893

    Medium · CVSS 5.5EPSS 0.23%Fix available

    net/sched: act_skbmod: prevent kernel-infoleak

    In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: prevent kernel-infoleak syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1]. The issue here is that 'struct tc_skbmod' has a four bytes hole. We need to clear the structure before filling fields. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 in

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2024-35890

    High · CVSS 7.8EPSS 0.24%Fix available

    gro: fix ownership transfer

    In the Linux kernel, the following vulnerability has been resolved: gro: fix ownership transfer If packets are GROed with fraglist they might be segmented later on and continue their journey in the stack. In skb_segment_list those skbs can be reused as-is. This is an issue as their destructor was removed in skb_gro_receive_list but not the reference to their socket, and then they can't be orphaned. Fix this by also removing the reference to the socket. For example this could be observed, kernel BUG at include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Call Trace: ipv6_list_rcv+0x250/0x3f0 __netif_r

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2024-35888

    High · CVSS 7.3EPSS 0.61%Fix available

    erspan: make sure erspan_base_hdr is present in skb->head

    In the Linux kernel, the following vulnerability has been resolved: erspan: make sure erspan_base_hdr is present in skb->head syzbot reported a problem in ip6erspan_rcv() [1] Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it. Add the missing pskb_may_pull() calls. v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed. [1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [i

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2024-35886

    High · CVSS 7.8EPSS 0.28%Fix available

    ipv6: Fix infinite recursion in fib6_dump_done().

    In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix infinite recursion in fib6_dump_done(). syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1] From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0] 12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8) Here, fib6_dump_done() was

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2024-35885

    Medium · CVSS 5.5EPSS 0.23%Fix available

    mlxbf_gige: stop interface during shutdown

    In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: stop interface during shutdown The mlxbf_gige driver intermittantly encounters a NULL pointer exception while the system is shutting down via "reboot" command. The mlxbf_driver will experience an exception right after executing its shutdown() method. One example of this exception is: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, I

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2024-35884

    Critical · CVSS 9.8EPSS 0.69%Fix available

    udp: do not accept non-tunnel GSO skbs landing in a tunnel

    In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2024-35879

    High · CVSS 7.8EPSS 0.24%Fix available

    of: dynamic: Synchronize of_changeset_destroy() with the devlink removals

    In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2024-35877

    Medium · CVSS 5.5EPSS 0.25%Fix available

    x86/mm/pat: fix VM_PAT handling in COW mappings

    In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(

    linux-nvidia-tegra-5.15Operating systems
    • Update to 5.15.0-1027.27~20.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

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

Check your server →