CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39506 – liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
https://notcve.org/view.php?id=CVE-2024-39506
In the Linux kernel, the following vulnerability has been resolved: liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/1f233f327913f3dee0602cba9c64df1903772b55 https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2 https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79 https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347 https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-39505 – drm/komeda: check for error-valued pointer
https://notcve.org/view.php?id=CVE-2024-39505
In the Linux kernel, the following vulnerability has been resolved: drm/komeda: check for error-valued pointer komeda_pipeline_get_state() may return an error-valued pointer, thus check the pointer for negative or null value before dereferencing. • https://git.kernel.org/stable/c/502932a03fceca1cb161eba5f30b18eb640aa8de https://git.kernel.org/stable/c/0674ed1e58e2fdcc155e7d944f8aad007a94ac69 https://git.kernel.org/stable/c/bda7cdaeebf57e46c1a488ae7a15f6f264691f59 https://git.kernel.org/stable/c/86042e3d16b7e0686db835c9e7af0f9044dd3a56 https://git.kernel.org/stable/c/3b1cf943b029c147bfacfd53dc28ffa632c0a622 https://git.kernel.org/stable/c/9460961d82134ceda7377b77a3e3e3531b625dfe https://git.kernel.org/stable/c/99392c98b9be0523fe76944b2264b1847512ad23 https://git.kernel.org/stable/c/b880018edd3a577e50366338194dee9b8 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39503 – netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type
https://notcve.org/view.php?id=CVE-2024-39503
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type Lion Ackermann reported that there is a race condition between namespace cleanup in ipset and the garbage collection of the list:set type. The namespace cleanup can destroy the list:set type of sets while the gc of the set type is waiting to run in rcu cleanup. The latter uses data from the destroyed set which thus leads use after free. The patch contains the following parts: - When destroying all sets, first remove the garbage collectors, then wait if needed and then destroy the sets. - Fix the badly ordered "wait then remove gc" for the destroy a single set case. - Fix the missing rcu locking in the list:set type in the userspace test case. - Use proper RCU list handlings in the list:set type. The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc). • https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225 https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05 https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49 https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397 https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001 https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb https://git.kernel.org/stable/c/c0761d1f1ce1d5b85b5e82bbb714df12d •
CVSS: 6.7EPSS: 0%CPEs: 7EXPL: 0CVE-2024-39502 – ionic: fix use after netif_napi_del()
https://notcve.org/view.php?id=CVE-2024-39502
In the Linux kernel, the following vulnerability has been resolved: ionic: fix use after netif_napi_del() When queues are started, netif_napi_add() and napi_enable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionic_qcq_enable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netif_napi_add(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netif_napi_del() doesn't reset the .poll pointer to NULL. So, ionic_qcq_enable() calls napi_enable() for the queue, which was unregistered by netif_napi_del(). Reproducer: ethtool -L <interface name> rx 1 tx 1 combined 0 ethtool -L <interface name> rx 0 tx 0 combined 1 ethtool -L <interface name> rx 0 tx 0 combined 4 Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? • https://git.kernel.org/stable/c/0f3154e6bcb354968cc04f7cd86ce466f7b9a814 https://git.kernel.org/stable/c/0d19267cb150e8f76ade210e16ee820a77f684e7 https://git.kernel.org/stable/c/ff9c2a9426ecf5b9631e9fd74993b357262387d6 https://git.kernel.org/stable/c/8edd18dab443863e9e48f084e7f123fca3065e4e https://git.kernel.org/stable/c/60cd714871cd5a683353a355cbb17a685245cf84 https://git.kernel.org/stable/c/183ebc167a8a19e916b885d4bb61a3491991bfa5 https://git.kernel.org/stable/c/a87d72b37b9ec2c1e18fe36b09241d8b30334a2e https://git.kernel.org/stable/c/79f18a41dd056115d685f3b0a419c7cd4 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39501 – drivers: core: synchronize really_probe() and dev_uevent()
https://notcve.org/view.php?id=CVE-2024-39501
In the Linux kernel, the following vulnerability has been resolved: drivers: core: synchronize really_probe() and dev_uevent() Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization: Thread #1: ========== really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... } Thread #2: ========== dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... } really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. • https://git.kernel.org/stable/c/239378f16aa1ab5c502e42a06359d2de4f88ebb4 https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080 https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721 https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69 https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90 https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea •