p PatchFirst

PatchFirst · Latest vulnerabilities

linux-nvidia-tegra-5.15 vulnerabilities · Page 103

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-2024-27414

    High · CVSS 7.8EPSS 0.23%Fix available

    rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back

    In the Linux kernel, the following vulnerability has been resolved: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic in the function `rtnl_bridge_setlink` to enable the loop to also check the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment removed the `break` statement and led to an error logic of the flags writing back at the end of this function. if (have_flags) memcpy(nla_data(attr), &flags, sizeof(flags)); // attr should point to IFLA_BRIDGE_FLAGS NLA !!!

    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-27413

    Medium · CVSS 5.5EPSS 0.25%Fix available

    efi/capsule-loader: fix incorrect allocation size

    In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect allocation size gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here.

    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-27412

    Medium · CVSS 5.5EPSS 0.25%Fix available

    power: supply: bq27xxx-i2c: Do not free non existing IRQ

    In the Linux kernel, the following vulnerability has been resolved: power: supply: bq27xxx-i2c: Do not free non existing IRQ The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq(). But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to: [ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 Followed by a backtrace when unbinding the driver. Add a

    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-27410

    High · CVSS 7.8EPSS 0.26%Fix available

    wifi: nl80211: reject iftype change with mesh ID change

    In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject iftype change with mesh ID change It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallo

    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-27405

    High · CVSS 7.5EPSS 1.3%Fix available

    usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

    In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Add

    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-27403

    High · CVSS 7.8EPSS 0.24%Fix available

    netfilter: nft_flow_offload: reset dst in route object after setting up flow

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_flow_offload: reset dst in route object after setting up flow dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow.

    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-27401

    High · CVSS 7.8EPSS 0.3%Fix available

    firewire: nosy: ensure user_length is taken into account when fetching packet contents

    In the Linux kernel, the following vulnerability has been resolved: firewire: nosy: ensure user_length is taken into account when fetching packet contents Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.

    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-27399

    Medium · CVSS 6EPSS 0.3%Fix available

    Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below: [ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308

    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-27398

    High · CVSS 8EPSS 0.83%Fix available

    Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout

    In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout When the sco connection is established and then, the sco socket is releasing, timeout_work will be scheduled to judge whether the sco disconnection is timeout. The sock will be deallocated later, but it is dereferenced again in sco_sock_timeout. As a result, the use-after-free bugs will happen. The root cause is shown below: Cleanup Thread | Worker Thread sco_sock_release | sco_sock_close | __sco_sock_close | sco_sock_set_timer

    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-2023-52655

    Medium · CVSS 5.5EPSS 0.27%Fix available

    usb: aqc111: check packet for fixup for true limit

    In the Linux kernel, the following vulnerability has been resolved: usb: aqc111: check packet for fixup for true limit If a device sends a packet that is inbetween 0 and sizeof(u64) the value passed to skb_trim() as length will wrap around ending up as some very large value. The driver will then proceed to parse the header located at that position, which will either oops or process some random value. The fix is to check against sizeof(u64) rather than 0, which the driver currently does. The issue exists since the introduction of the driver.

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

  13. CVE-2024-27397

    High · CVSS 7.8EPSS 0.26%Fix available

    netfilter: nf_tables: use timestamp to check for set element timeout

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: use timestamp to check for set element timeout Add a timestamp field at the beginning of the transaction, store it in the nftables per-netns area. Update set backend .insert, .deactivate and sync gc path to use the timestamp, this avoids that an element expires while control plane transaction is still unfinished. .lookup and .update, which are used from packet path, still use the current time to check if the element has expired. And .get path and dump also since this runs lockless under rcu read size lock. Then, there is async gc which also needs to

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

  14. CVE-2024-27396

    High · CVSS 7.8EPSS 0.24%Fix available

    net: gtp: Fix Use-After-Free in gtp_dellink

    In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.

    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-27395

    High · CVSS 7.8EPSS 0.24%Fix available

    net: openvswitch: Fix Use-After-Free in ovs_ct_exit

    In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.

    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-27393

    High · CVSS 7.5EPSS 0.77%Fix available

    xen-netfront: Add missing skb_mark_for_recycle

    In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-pa

    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-27390

    Medium · CVSS 5.8EPSS 0.22%Fix available

    ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down()

    In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well.

    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-27388

    Critical · CVSS 9.8EPSS 0.96%Fix available

    SUNRPC: fix some memleaks in gssx_dec_option_array

    In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.

    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-27078

    Medium · CVSS 5.5EPSS 0.29%Fix available

    media: v4l2-tpg: fix some memleaks in tpg_alloc

    In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0.

    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-27077

    Medium · CVSS 5.5EPSS 0.29%Fix available

    media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity

    In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.

    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 →