CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2025-21678 – gtp: Destroy device along with udp socket's netns dismantle.
https://notcve.org/view.php?id=CVE-2025-21678
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: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-21675 – net/mlx5: Clear port select structure when fail to create
https://notcve.org/view.php?id=CVE-2025-21675
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: 5EXPL: 0CVE-2025-21673 – smb: client: fix double free of TCP_Server_Info::hostname
https://notcve.org/view.php?id=CVE-2025-21673
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: 0CVE-2025-21672 – afs: Fix merge preference rule failure condition
https://notcve.org/view.php?id=CVE-2025-21672
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: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2025-21669 – vsock/virtio: discard packets if the transport changes
https://notcve.org/view.php?id=CVE-2025-21669
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 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-21667 – iomap: avoid avoid truncating 64-bit offset to 32 bits
https://notcve.org/view.php?id=CVE-2025-21667
31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: iomap: avoid avoid truncating 64-bit offset to 32 bits on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a 32-bit position due to folio_next_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem. In the Linux kernel, the following vulnerability has been resolved: iomap: avoid avoid truncating 64-bit offset to 32 bits on 32-bit kernels, iomap_write_delalloc_scan() was i... • https://git.kernel.org/stable/c/7ca4bd6b754913910151acce00be093f03642725 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2025-21666 – vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]
https://notcve.org/view.php?id=CVE-2025-21666
31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: vsock: prevent null-ptr-deref in vsock_*[has_data|has_space] Recent reports have shown how we sometimes call vsock_*_has_data() when a vsock socket has been de-assigned from a transport (see attached links), but we shouldn't. Previous commits should have solved the real problems, but we may have more in the future, so to avoid null-ptr-deref, we can return 0 (no space, no data available) but with a warning. This way the code should continue... • https://git.kernel.org/stable/c/c0cfa2d8a788fcf45df5bf4070ab2474c88d543a •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21665 – filemap: avoid truncating 64-bit offset to 32 bits
https://notcve.org/view.php?id=CVE-2025-21665
31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: filemap: avoid truncating 64-bit offset to 32 bits On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a 64-bit value to 32 bits, leading to a possible infinite loop when writing to an xfs filesystem. In the Linux kernel, the following vulnerability has been resolved: filemap: avoid truncating 64-bit offset to 32 bits On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a 64-bit value to 32 bits, leading... • https://git.kernel.org/stable/c/54fa39ac2e00b1b8c2a7fe72e648773ffa48f76d •
CVSS: 7.1EPSS: 0%CPEs: 7EXPL: 0CVE-2024-57948 – mac802154: check local interfaces before deleting sdata list
https://notcve.org/view.php?id=CVE-2024-57948
31 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: mac802154: check local interfaces before deleting sdata list syzkaller reported a corrupted list in ieee802154_if_remove. [1] Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 hardware device from the system. CPU0 CPU1 ==== ==== genl_family_rcv_msg_doit ieee802154_unregister_hw ieee802154_del_iface ieee802154_remove_interfaces rdev_del_virtual_intf_deprecated list_del(&sdata->list) ieee802154_if_remove list_del_rcu... • https://git.kernel.org/stable/c/0d11dc30edfc4acef0acef130bb5ca596317190a •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-57947 – netfilter: nf_set_pipapo: fix initial map fill
https://notcve.org/view.php?id=CVE-2024-57947
23 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo: fix initial map fill The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size. After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map. This makes pipapo find an incorrect match... • https://git.kernel.org/stable/c/3c4287f62044a90e73a561aa05fc46e62da173da •