Page 4 of 4572 results (0.013 seconds)

CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: gtp: Destroy device along with udp socket's netns dismantle. gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created. Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0] In this example, gtp0 is created in ns2, and the udp socket is created in ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 nam... • https://git.kernel.org/stable/c/459aa660eb1d8ce67080da1983bb81d716aa5a69 •

CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: pfcp: Destroy device along with udp socket's netns dismantle. pfcp_newlink() links the device to a list in dev_net(dev) instead of net, where a udp tunnel socket is created. Even when net is removed, the device stays alive on dev_net(dev). Then, removing net triggers the splat below. [0] In this example, pfcp0 is created in ns2, but the udp socket is created in ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name pfcp0 t... • https://git.kernel.org/stable/c/76c8764ef36a5d37ea2e551bda28ac7f028383ba •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: net: fec: handle page_pool_dev_alloc_pages error The fec_enet_update_cbd function calls page_pool_dev_alloc_pages but did not handle the case when it returned NULL. There was a WARN_ON(!new_page) but it would still proceed to use the NULL pointer and then crash. This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd sha... • https://git.kernel.org/stable/c/95698ff6177b5f1f13f251da60e7348413046ae4 •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Clear port select structure when fail to create Clear the port select structure on error so no stale values left after definers are destroyed. That's because the mlx5_lag_destroy_definers() always try to destroy all lag definers in the tt_map, so in the flow below lag definers get double-destroyed and cause kernel crash: mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 1 mlx5_lag_dest... • https://git.kernel.org/stable/c/dc48516ec7d369c6b80bf9f14d774287b6c428aa •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix inversion dependency warning while enabling IPsec tunnel Attempt to enable IPsec packet offload in tunnel mode in debug kernel generates the following kernel panic, which is happening due to two issues: 1. In SA add section, the should be _bh() variant when marking SA mode. 2. There is not needed flush_workqueue in SA delete routine. It is not needed as at this stage as it is removed from SADB and the running work will be can... • https://git.kernel.org/stable/c/4c24272b4e2befca6ad1409c3c9aaa16c24b1099 •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double free of TCP_Server_Info::hostname When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf ... • https://git.kernel.org/stable/c/7be3248f313930ff3d3436d4e9ddbe9fccc1f541 •

CVSS: 5.6EPSS: 0%CPEs: 2EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: afs: Fix merge preference rule failure condition syzbot reported a lock held when returning to userspace[1]. This is because if argc is less than 0 and the function returns directly, the held inode lock is not released. Fix this by store the error in ret and jump to done to clean up instead of returning directly. [dh: Modified Lizhi Xu's original patch to make it honour the error code from afs_split_string()] [1] WARNING: lock held when ret... • https://git.kernel.org/stable/c/22be1d90a6211c88dd093b25d1f3aa974d0d9f9d •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: zram: fix potential UAF of zram table If zram_meta_alloc failed early, it frees allocated zram->table without setting it NULL. Which will potentially cause zram_meta_free to access the table if user reset an failed and uninitialized device. In the Linux kernel, the following vulnerability has been resolved: zram: fix potential UAF of zram table If zram_meta_alloc failed early, it frees allocated zram->table without setting it NULL. Which wi... • https://git.kernel.org/stable/c/ac3b5366b9b7c9d97b606532ceab43d2329a22f3 • CWE-416: Use After Free •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: vsock/bpf: return early if transport is not assigned Some of the core functions can only be called if the transport has been assigned. As Michal reported, a socket might have the transport at NULL, for example after a failed connect(), causing the following trace: BUG: kernel NULL pointer dereference, address: 00000000000000a0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 12faf8067 P4D 12faf8067 P... • https://git.kernel.org/stable/c/634f1a7110b439c65fd8a809171c1d2d28bcea6f •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: discard packets if the transport changes If the socket has been de-assigned or assigned to another transport, we must discard any packets received because they are not expected and would cause issues when we access vsk->transport. A possible scenario is described by Hyunwoo Kim in the attached link, where after a first connect() interrupted by a signal, and a second connect() failed, we can find `vsk->transport` at NULL, leadi... • https://git.kernel.org/stable/c/c0cfa2d8a788fcf45df5bf4070ab2474c88d543a •