{
"summary": {
"snap": {
"added": [],
"removed": [],
"diff": []
},
"deb": {
"added": [
"linux-headers-6.17.0-29",
"linux-headers-6.17.0-29-generic",
"linux-image-6.17.0-29-generic",
"linux-modules-6.17.0-29-generic",
"linux-tools-6.17.0-29",
"linux-tools-6.17.0-29-generic"
],
"removed": [
"linux-headers-6.17.0-22",
"linux-headers-6.17.0-22-generic",
"linux-image-6.17.0-22-generic",
"linux-modules-6.17.0-22-generic",
"linux-tools-6.17.0-22",
"linux-tools-6.17.0-22-generic"
],
"diff": [
"bpftool",
"curl",
"distro-info-data",
"dpkg",
"kmod",
"libcurl3t64-gnutls",
"libcurl4t64",
"libgnutls30t64",
"libkmod2",
"libnghttp2-14",
"libpng16-16t64",
"linux-headers-generic",
"linux-headers-virtual",
"linux-image-virtual",
"linux-libc-dev",
"linux-perf",
"linux-tools-common",
"linux-virtual",
"openssh-client",
"openssh-server",
"openssh-sftp-server",
"python3-distupgrade",
"rsync",
"sed",
"ubuntu-release-upgrader-core",
"vim",
"vim-common",
"vim-runtime",
"vim-tiny",
"xxd"
]
}
},
"diff": {
"deb": [
{
"name": "bpftool",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "7.7.0+6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "7.7.0+6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "curl",
"from_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.2",
"version": "8.14.1-2ubuntu1.2"
},
"to_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.3",
"version": "8.14.1-2ubuntu1.3"
},
"cves": [
{
"cve": "CVE-2026-4873",
"url": "https://ubuntu.com/security/CVE-2026-4873",
"cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5545",
"url": "https://ubuntu.com/security/CVE-2026-5545",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5773",
"url": "https://ubuntu.com/security/CVE-2026-5773",
"cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6253",
"url": "https://ubuntu.com/security/CVE-2026-6253",
"cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6276",
"url": "https://ubuntu.com/security/CVE-2026-6276",
"cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6429",
"url": "https://ubuntu.com/security/CVE-2026-6429",
"cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-7168",
"url": "https://ubuntu.com/security/CVE-2026-7168",
"cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-4873",
"url": "https://ubuntu.com/security/CVE-2026-4873",
"cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5545",
"url": "https://ubuntu.com/security/CVE-2026-5545",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5773",
"url": "https://ubuntu.com/security/CVE-2026-5773",
"cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6253",
"url": "https://ubuntu.com/security/CVE-2026-6253",
"cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6276",
"url": "https://ubuntu.com/security/CVE-2026-6276",
"cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6429",
"url": "https://ubuntu.com/security/CVE-2026-6429",
"cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-7168",
"url": "https://ubuntu.com/security/CVE-2026-7168",
"cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: connection reuse ignores TLS requirement",
" - debian/patches/CVE-2026-4873.patch: do not reuse a non-tls starttls",
" connection if new requires TLS in lib/url.c.",
" - CVE-2026-4873",
" * SECURITY UPDATE: wrong reuse of HTTP Negotiate connection",
" - debian/patches/CVE-2026-5545.patch: improve connection reuse on",
" negotiate in lib/url.c.",
" - CVE-2026-5545",
" * SECURITY UPDATE: wrong reuse of SMB connection",
" - debian/patches/CVE-2026-5773.patch: disable connection reuse for",
" SMB(S) in lib/smb.c.",
" - CVE-2026-5773",
" * SECURITY UPDATE: proxy credentials leak over redirect-to proxy",
" - debian/patches/CVE-2026-6253-pre1.patch: chunked response, error code",
" in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c, tests/*.",
" - debian/patches/CVE-2026-6253-pre2.patch: fix error code, remove SMB",
" use in tests/data/test445.",
" - debian/patches/CVE-2026-6253.patch: clear the proxy credentials as",
" well on port or scheme change in lib/http.c, lib/transfer.*, tests/*.",
" - CVE-2026-6253",
" * SECURITY UPDATE: stale custom cookie host causes cookie leak",
" - debian/patches/CVE-2026-6276.patch: move cookiehost to struct",
" SingleRequest in lib/http.c, lib/request.c, lib/request.h, lib/url.c,",
" lib/urldata.h, tests/*.",
" - CVE-2026-6276",
" * SECURITY UPDATE: netrc credential leak with reused proxy connection",
" - debian/patches/CVE-2026-6429-pre1.patch: prevent secure schemes",
" pushed over insecure connections in lib/http2.c.",
" - debian/patches/CVE-2026-6429-pre2.patch: same origin tests in",
" lib/http2.c, lib/urlapi-int.h, lib/urlapi.c.",
" - debian/patches/CVE-2026-6429.patch: clear credentials better on",
" redirect in lib/http.c, tests/*.",
" - CVE-2026-6429",
" * SECURITY UPDATE: cross-proxy Digest auth state leak",
" - debian/patches/CVE-2026-7168.patch: clear proxy auth properties when",
" switching in lib/setopt.c, lib/vauth/vauth.h, tests/*.",
" - CVE-2026-7168",
""
],
"package": "curl",
"version": "8.14.1-2ubuntu1.3",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Wed, 29 Apr 2026 07:35:43 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "distro-info-data",
"from_version": {
"source_package_name": "distro-info-data",
"source_package_version": "0.66ubuntu0.1",
"version": "0.66ubuntu0.1"
},
"to_version": {
"source_package_name": "distro-info-data",
"source_package_version": "0.66ubuntu0.2",
"version": "0.66ubuntu0.2"
},
"cves": [],
"launchpad_bugs_fixed": [
2150234
],
"changes": [
{
"cves": [],
"log": [
"",
" * Add Ubuntu 26.10 \"Stonking Stingray\" (LP: #2150234)",
""
],
"package": "distro-info-data",
"version": "0.66ubuntu0.2",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150234
],
"author": "Oliver Reiche ",
"date": "Tue, 28 Apr 2026 15:43:51 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "dpkg",
"from_version": {
"source_package_name": "dpkg",
"source_package_version": "1.22.21ubuntu3.1",
"version": "1.22.21ubuntu3.1"
},
"to_version": {
"source_package_name": "dpkg",
"source_package_version": "1.22.21ubuntu3.2",
"version": "1.22.21ubuntu3.2"
},
"cves": [
{
"cve": "CVE-2026-2219",
"url": "https://ubuntu.com/security/CVE-2026-2219",
"cve_description": "It was discovered that dpkg-deb (a component of dpkg, the Debian package management system) does not properly validate the end of the data stream when uncompressing a zstd-compressed .deb archive, which may result in denial of service (infinite loop spinning the CPU).",
"cve_priority": "medium",
"cve_public_date": "2026-03-07 09:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-2219",
"url": "https://ubuntu.com/security/CVE-2026-2219",
"cve_description": "It was discovered that dpkg-deb (a component of dpkg, the Debian package management system) does not properly validate the end of the data stream when uncompressing a zstd-compressed .deb archive, which may result in denial of service (infinite loop spinning the CPU).",
"cve_priority": "medium",
"cve_public_date": "2026-03-07 09:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: infinite loop uncompressing a zstd-compressed .deb archive",
" - lib/dpkg/compress.c: terminate zstd decompression when we have no",
" more data.",
" - 6610297a62c0780dd0e80b0e302ef64fdcc9d313",
" - CVE-2026-2219",
""
],
"package": "dpkg",
"version": "1.22.21ubuntu3.2",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Wed, 06 May 2026 13:35:53 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "kmod",
"from_version": {
"source_package_name": "kmod",
"source_package_version": "34.2-2ubuntu1",
"version": "34.2-2ubuntu1"
},
"to_version": {
"source_package_name": "kmod",
"source_package_version": "34.2-2ubuntu1.1",
"version": "34.2-2ubuntu1.1"
},
"cves": [
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2150743
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
}
],
"log": [
"",
" * Disable loading of algif_aead module to mitigate CVE-2026-31431",
" (LP: #2150743)",
" - debian/modprobe.d/disable-algif_aead.conf",
""
],
"package": "kmod",
"version": "34.2-2ubuntu1.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [
2150743
],
"author": "Marc Deslauriers ",
"date": "Thu, 30 Apr 2026 08:31:34 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libcurl3t64-gnutls",
"from_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.2",
"version": "8.14.1-2ubuntu1.2"
},
"to_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.3",
"version": "8.14.1-2ubuntu1.3"
},
"cves": [
{
"cve": "CVE-2026-4873",
"url": "https://ubuntu.com/security/CVE-2026-4873",
"cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5545",
"url": "https://ubuntu.com/security/CVE-2026-5545",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5773",
"url": "https://ubuntu.com/security/CVE-2026-5773",
"cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6253",
"url": "https://ubuntu.com/security/CVE-2026-6253",
"cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6276",
"url": "https://ubuntu.com/security/CVE-2026-6276",
"cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6429",
"url": "https://ubuntu.com/security/CVE-2026-6429",
"cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-7168",
"url": "https://ubuntu.com/security/CVE-2026-7168",
"cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-4873",
"url": "https://ubuntu.com/security/CVE-2026-4873",
"cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5545",
"url": "https://ubuntu.com/security/CVE-2026-5545",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5773",
"url": "https://ubuntu.com/security/CVE-2026-5773",
"cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6253",
"url": "https://ubuntu.com/security/CVE-2026-6253",
"cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6276",
"url": "https://ubuntu.com/security/CVE-2026-6276",
"cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6429",
"url": "https://ubuntu.com/security/CVE-2026-6429",
"cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-7168",
"url": "https://ubuntu.com/security/CVE-2026-7168",
"cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: connection reuse ignores TLS requirement",
" - debian/patches/CVE-2026-4873.patch: do not reuse a non-tls starttls",
" connection if new requires TLS in lib/url.c.",
" - CVE-2026-4873",
" * SECURITY UPDATE: wrong reuse of HTTP Negotiate connection",
" - debian/patches/CVE-2026-5545.patch: improve connection reuse on",
" negotiate in lib/url.c.",
" - CVE-2026-5545",
" * SECURITY UPDATE: wrong reuse of SMB connection",
" - debian/patches/CVE-2026-5773.patch: disable connection reuse for",
" SMB(S) in lib/smb.c.",
" - CVE-2026-5773",
" * SECURITY UPDATE: proxy credentials leak over redirect-to proxy",
" - debian/patches/CVE-2026-6253-pre1.patch: chunked response, error code",
" in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c, tests/*.",
" - debian/patches/CVE-2026-6253-pre2.patch: fix error code, remove SMB",
" use in tests/data/test445.",
" - debian/patches/CVE-2026-6253.patch: clear the proxy credentials as",
" well on port or scheme change in lib/http.c, lib/transfer.*, tests/*.",
" - CVE-2026-6253",
" * SECURITY UPDATE: stale custom cookie host causes cookie leak",
" - debian/patches/CVE-2026-6276.patch: move cookiehost to struct",
" SingleRequest in lib/http.c, lib/request.c, lib/request.h, lib/url.c,",
" lib/urldata.h, tests/*.",
" - CVE-2026-6276",
" * SECURITY UPDATE: netrc credential leak with reused proxy connection",
" - debian/patches/CVE-2026-6429-pre1.patch: prevent secure schemes",
" pushed over insecure connections in lib/http2.c.",
" - debian/patches/CVE-2026-6429-pre2.patch: same origin tests in",
" lib/http2.c, lib/urlapi-int.h, lib/urlapi.c.",
" - debian/patches/CVE-2026-6429.patch: clear credentials better on",
" redirect in lib/http.c, tests/*.",
" - CVE-2026-6429",
" * SECURITY UPDATE: cross-proxy Digest auth state leak",
" - debian/patches/CVE-2026-7168.patch: clear proxy auth properties when",
" switching in lib/setopt.c, lib/vauth/vauth.h, tests/*.",
" - CVE-2026-7168",
""
],
"package": "curl",
"version": "8.14.1-2ubuntu1.3",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Wed, 29 Apr 2026 07:35:43 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libcurl4t64",
"from_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.2",
"version": "8.14.1-2ubuntu1.2"
},
"to_version": {
"source_package_name": "curl",
"source_package_version": "8.14.1-2ubuntu1.3",
"version": "8.14.1-2ubuntu1.3"
},
"cves": [
{
"cve": "CVE-2026-4873",
"url": "https://ubuntu.com/security/CVE-2026-4873",
"cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5545",
"url": "https://ubuntu.com/security/CVE-2026-5545",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5773",
"url": "https://ubuntu.com/security/CVE-2026-5773",
"cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6253",
"url": "https://ubuntu.com/security/CVE-2026-6253",
"cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6276",
"url": "https://ubuntu.com/security/CVE-2026-6276",
"cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6429",
"url": "https://ubuntu.com/security/CVE-2026-6429",
"cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-7168",
"url": "https://ubuntu.com/security/CVE-2026-7168",
"cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-4873",
"url": "https://ubuntu.com/security/CVE-2026-4873",
"cve_description": "A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5545",
"url": "https://ubuntu.com/security/CVE-2026-5545",
"cve_description": "libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-5773",
"url": "https://ubuntu.com/security/CVE-2026-5773",
"cve_description": "libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6253",
"url": "https://ubuntu.com/security/CVE-2026-6253",
"cve_description": "curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say `http://`), curl is asked to follow a redirect to a URL using another scheme (say `https://`), accessed using a second, different, proxy",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6276",
"url": "https://ubuntu.com/security/CVE-2026-6276",
"cve_description": "Using libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently done using the same *easy handle* but without the custom `Host:` header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.",
"cve_priority": "low",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-6429",
"url": "https://ubuntu.com/security/CVE-2026-6429",
"cve_description": "When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
},
{
"cve": "CVE-2026-7168",
"url": "https://ubuntu.com/security/CVE-2026-7168",
"cve_description": "Successfully using libcurl to do a transfer over a specific HTTP proxy (`proxyA`) with **Digest** authentication and then changing the proxy host to a second one (`proxyB`) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the `Proxy-Authorization:` header field meant for `proxyA`, to `proxyB`.",
"cve_priority": "medium",
"cve_public_date": "2026-05-13 13:01:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: connection reuse ignores TLS requirement",
" - debian/patches/CVE-2026-4873.patch: do not reuse a non-tls starttls",
" connection if new requires TLS in lib/url.c.",
" - CVE-2026-4873",
" * SECURITY UPDATE: wrong reuse of HTTP Negotiate connection",
" - debian/patches/CVE-2026-5545.patch: improve connection reuse on",
" negotiate in lib/url.c.",
" - CVE-2026-5545",
" * SECURITY UPDATE: wrong reuse of SMB connection",
" - debian/patches/CVE-2026-5773.patch: disable connection reuse for",
" SMB(S) in lib/smb.c.",
" - CVE-2026-5773",
" * SECURITY UPDATE: proxy credentials leak over redirect-to proxy",
" - debian/patches/CVE-2026-6253-pre1.patch: chunked response, error code",
" in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c, tests/*.",
" - debian/patches/CVE-2026-6253-pre2.patch: fix error code, remove SMB",
" use in tests/data/test445.",
" - debian/patches/CVE-2026-6253.patch: clear the proxy credentials as",
" well on port or scheme change in lib/http.c, lib/transfer.*, tests/*.",
" - CVE-2026-6253",
" * SECURITY UPDATE: stale custom cookie host causes cookie leak",
" - debian/patches/CVE-2026-6276.patch: move cookiehost to struct",
" SingleRequest in lib/http.c, lib/request.c, lib/request.h, lib/url.c,",
" lib/urldata.h, tests/*.",
" - CVE-2026-6276",
" * SECURITY UPDATE: netrc credential leak with reused proxy connection",
" - debian/patches/CVE-2026-6429-pre1.patch: prevent secure schemes",
" pushed over insecure connections in lib/http2.c.",
" - debian/patches/CVE-2026-6429-pre2.patch: same origin tests in",
" lib/http2.c, lib/urlapi-int.h, lib/urlapi.c.",
" - debian/patches/CVE-2026-6429.patch: clear credentials better on",
" redirect in lib/http.c, tests/*.",
" - CVE-2026-6429",
" * SECURITY UPDATE: cross-proxy Digest auth state leak",
" - debian/patches/CVE-2026-7168.patch: clear proxy auth properties when",
" switching in lib/setopt.c, lib/vauth/vauth.h, tests/*.",
" - CVE-2026-7168",
""
],
"package": "curl",
"version": "8.14.1-2ubuntu1.3",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Wed, 29 Apr 2026 07:35:43 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libgnutls30t64",
"from_version": {
"source_package_name": "gnutls28",
"source_package_version": "3.8.9-3ubuntu2.1",
"version": "3.8.9-3ubuntu2.1"
},
"to_version": {
"source_package_name": "gnutls28",
"source_package_version": "3.8.9-3ubuntu2.2",
"version": "3.8.9-3ubuntu2.2"
},
"cves": [
{
"cve": "CVE-2026-33846",
"url": "https://ubuntu.com/security/CVE-2026-33846",
"cve_description": "A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.",
"cve_priority": "medium",
"cve_public_date": "2026-05-04 10:15:00 UTC"
},
{
"cve": "CVE-2026-42009",
"url": "https://ubuntu.com/security/CVE-2026-42009",
"cve_description": "A flaw was found in gnutls. A remote attacker could exploit an issue in the Datagram Transport Layer Security (DTLS) packet reordering logic. The comparator function, responsible for ordering DTLS packets by sequence numbers, did not correctly handle packets with duplicate sequence numbers. This could lead to unstable packet ordering or undefined behavior, resulting in a denial of service.",
"cve_priority": "medium",
"cve_public_date": "2026-05-18 13:16:00 UTC"
},
{
"cve": "CVE-2026-33845",
"url": "https://ubuntu.com/security/CVE-2026-33845",
"cve_description": "A flaw in GnuTLS DTLS handshake parsing allows malformed fragments with zero length and non-zero offset, leading to an integer underflow during reassembly and resulting in an out-of-bounds read. This issue is remotely exploitable and may cause information disclosure or denial of service.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30 18:16:00 UTC"
},
{
"cve": "CVE-2026-3832",
"url": "https://ubuntu.com/security/CVE-2026-3832",
"cve_description": "A flaw was found in gnutls. A remote attacker could exploit this vulnerability by presenting a specially crafted Online Certificate Status Protocol (OCSP) response during a TLS handshake. Due to a logic error in how gnutls processes multi-record OCSP responses, a client with OCSP verification enabled may incorrectly accept a revoked server certificate, potentially leading to a compromise of trust.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30 18:16:00 UTC"
},
{
"cve": "CVE-2026-3833",
"url": "https://ubuntu.com/security/CVE-2026-3833",
"cve_description": "A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of `nameConstraints` labels, specifically for `dNSName` (DNS) or `rfc822Name` (email) constraints within `excludedSubtrees` or `permittedSubtrees`. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30 18:16:00 UTC"
},
{
"cve": "CVE-2026-42011",
"url": "https://ubuntu.com/security/CVE-2026-42011",
"cve_description": "A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems.",
"cve_priority": "medium",
"cve_public_date": "2026-05-07 15:16:00 UTC"
},
{
"cve": "CVE-2026-42010",
"url": "https://ubuntu.com/security/CVE-2026-42010",
"cve_description": "A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest–Shamir–Adleman – Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.",
"cve_priority": "medium",
"cve_public_date": "2026-05-07 12:16:00 UTC"
},
{
"cve": "CVE-2026-5260",
"url": "https://ubuntu.com/security/CVE-2026-5260",
"cve_description": "For a server using an RSA key backed by a PKCS#11 token, a client sending an extremely short premaster secret during an RSA key exchange could trigger a short heap overread.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42012",
"url": "https://ubuntu.com/security/CVE-2026-42012",
"cve_description": "Certificates containing URI or SRV Subject Alternative Names would fall back to checking DNS hostnames against Common Name, allowing potential misuse of such certificates beyond their original purpose.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42013",
"url": "https://ubuntu.com/security/CVE-2026-42013",
"cve_description": "Validation of certificates with oversized Subject Alternative Names would fall back to checking DNS hostnames against Common Name.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42014",
"url": "https://ubuntu.com/security/CVE-2026-42014",
"cve_description": "Changing the Security Officer PIN with gnutls_pkcs11_token_set_pin() with oldpin == NULL for a token lacking a protected authentication path led to a use-after-free.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42015",
"url": "https://ubuntu.com/security/CVE-2026-42015",
"cve_description": "Appending to a PKCS#12 bag that already contained 32 elements could write past the bag's internal array.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-5419",
"url": "https://ubuntu.com/security/CVE-2026-5419",
"cve_description": "The PKCS#7 padding check performed during decryption was not constant-time, potentially leaking information about the padding bytes through timing differences.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-33846",
"url": "https://ubuntu.com/security/CVE-2026-33846",
"cve_description": "A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.",
"cve_priority": "medium",
"cve_public_date": "2026-05-04 10:15:00 UTC"
},
{
"cve": "CVE-2026-42009",
"url": "https://ubuntu.com/security/CVE-2026-42009",
"cve_description": "A flaw was found in gnutls. A remote attacker could exploit an issue in the Datagram Transport Layer Security (DTLS) packet reordering logic. The comparator function, responsible for ordering DTLS packets by sequence numbers, did not correctly handle packets with duplicate sequence numbers. This could lead to unstable packet ordering or undefined behavior, resulting in a denial of service.",
"cve_priority": "medium",
"cve_public_date": "2026-05-18 13:16:00 UTC"
},
{
"cve": "CVE-2026-33845",
"url": "https://ubuntu.com/security/CVE-2026-33845",
"cve_description": "A flaw in GnuTLS DTLS handshake parsing allows malformed fragments with zero length and non-zero offset, leading to an integer underflow during reassembly and resulting in an out-of-bounds read. This issue is remotely exploitable and may cause information disclosure or denial of service.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30 18:16:00 UTC"
},
{
"cve": "CVE-2026-3832",
"url": "https://ubuntu.com/security/CVE-2026-3832",
"cve_description": "A flaw was found in gnutls. A remote attacker could exploit this vulnerability by presenting a specially crafted Online Certificate Status Protocol (OCSP) response during a TLS handshake. Due to a logic error in how gnutls processes multi-record OCSP responses, a client with OCSP verification enabled may incorrectly accept a revoked server certificate, potentially leading to a compromise of trust.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30 18:16:00 UTC"
},
{
"cve": "CVE-2026-3833",
"url": "https://ubuntu.com/security/CVE-2026-3833",
"cve_description": "A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of `nameConstraints` labels, specifically for `dNSName` (DNS) or `rfc822Name` (email) constraints within `excludedSubtrees` or `permittedSubtrees`. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30 18:16:00 UTC"
},
{
"cve": "CVE-2026-42011",
"url": "https://ubuntu.com/security/CVE-2026-42011",
"cve_description": "A flaw was found in gnutls. This vulnerability occurs because permitted name constraints were incorrectly ignored when previous Certificate Authorities (CAs) only had excluded name constraints. A remote attacker could exploit this to bypass critical name constraint checks during certificate validation. This bypass could lead to the acceptance of invalid certificates, potentially enabling spoofing or man-in-the-middle attacks against affected systems.",
"cve_priority": "medium",
"cve_public_date": "2026-05-07 15:16:00 UTC"
},
{
"cve": "CVE-2026-42010",
"url": "https://ubuntu.com/security/CVE-2026-42010",
"cve_description": "A flaw was found in gnutls. Servers configured with RSA-PSK (Rivest–Shamir–Adleman – Pre-Shared Key) wrongfully matched usernames containing a NUL character with truncated usernames. A remote attacker could exploit this by sending a specially crafted username, leading to an authentication bypass. This vulnerability allows an attacker to gain unauthorized access by circumventing the authentication process.",
"cve_priority": "medium",
"cve_public_date": "2026-05-07 12:16:00 UTC"
},
{
"cve": "CVE-2026-5260",
"url": "https://ubuntu.com/security/CVE-2026-5260",
"cve_description": "For a server using an RSA key backed by a PKCS#11 token, a client sending an extremely short premaster secret during an RSA key exchange could trigger a short heap overread.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42012",
"url": "https://ubuntu.com/security/CVE-2026-42012",
"cve_description": "Certificates containing URI or SRV Subject Alternative Names would fall back to checking DNS hostnames against Common Name, allowing potential misuse of such certificates beyond their original purpose.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42013",
"url": "https://ubuntu.com/security/CVE-2026-42013",
"cve_description": "Validation of certificates with oversized Subject Alternative Names would fall back to checking DNS hostnames against Common Name.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42014",
"url": "https://ubuntu.com/security/CVE-2026-42014",
"cve_description": "Changing the Security Officer PIN with gnutls_pkcs11_token_set_pin() with oldpin == NULL for a token lacking a protected authentication path led to a use-after-free.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-42015",
"url": "https://ubuntu.com/security/CVE-2026-42015",
"cve_description": "Appending to a PKCS#12 bag that already contained 32 elements could write past the bag's internal array.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
},
{
"cve": "CVE-2026-5419",
"url": "https://ubuntu.com/security/CVE-2026-5419",
"cve_description": "The PKCS#7 padding check performed during decryption was not constant-time, potentially leaking information about the padding bytes through timing differences.",
"cve_priority": "medium",
"cve_public_date": "2026-04-30"
}
],
"log": [
"",
" * SECURITY UPDATE: buffer overflow in DTLS handshake fragment reassembly",
" - debian/patches/CVE-2026-33846-pre1.patch: buffers: shorten",
" merge_handshake_packet using recv_buf in lib/buffers.c.",
" - debian/patches/CVE-2026-33846.patch: buffers: add more checks to DTLS",
" reassembly in lib/buffers.c.",
" - CVE-2026-33846",
" * SECURITY UPDATE: DTLS packets sequence number ordering issue",
" - debian/patches/CVE-2026-42009-pre1.patch: buffers: match DTLS datagrams by",
" sequence number in lib/buffers.c.",
" - debian/patches/CVE-2026-42009-1.patch: lib/buffers: ensure packets have",
" differing sequence numbers in lib/buffers.c.",
" - debian/patches/CVE-2026-42009-2.patch: buffers: fix handshake_compare when",
" sequence numbers match in lib/buffers.c.",
" - CVE-2026-42009",
" * SECURITY UPDATE: OOB read via malformed fragments with zero length and",
" non-zero offset",
" - debian/patches/CVE-2026-33845-pre1.patch: buffers: rename a variable in",
" parse_handshake_header in lib/buffers.c.",
" - debian/patches/CVE-2026-33845.patch: buffers: switch from end_offset over",
" to frag_length in lib/buffers.c, lib/gnutls_int.h.",
" - debian/patches/CVE-2026-33845-2.patch: buffers: simplify and tighten",
" parse_handshake_header checks in lib/buffers.c.",
" - CVE-2026-33845",
" * SECURITY UPDATE: malformed OCSP response issue",
" - debian/patches/CVE-2026-3832.patch: cert-session: fix multi-entry OCSP",
" revocation bypass in lib/cert-session.c.",
" - CVE-2026-3832",
" * SECURITY UPDATE: policy bypass via x509 case-sensitive comparisons",
" - debian/patches/CVE-2026-3833.patch: x509/name-constraints: compare domain",
" names case-insensitive in lib/x509/name_constraints.c.",
" - CVE-2026-3833",
" * SECURITY UPDATE: permitted name constrains were incorrectly ignored",
" - debian/patches/CVE-2026-42011.patch: x509/name_constraints: fix",
" intersecting empty constraints in lib/x509/name_constraints.c.",
" - CVE-2026-42011",
" * SECURITY UPDATE: ",
" - debian/patches/CVE-2026-42010.patch: lib/auth/rsa_psk: fix binary PSK",
" identity lookup in lib/auth/rsa_psk.c.",
" - CVE-2026-42010",
" * SECURITY UPDATE: incorrect username parsing with NUL characters",
" - debian/patches/CVE-2026-5260-1.patch: lib/auth/rsa: check that ciphertext",
" matches the modulus size in lib/auth/rsa.c, lib/auth/rsa_psk.c.",
" - debian/patches/CVE-2026-5260-2.patch: lib/pkcs11_privkey: guard against",
" overreading on short ciphertexts in lib/pkcs11_privkey.c.",
" - CVE-2026-5260",
" * SECURITY UPDATE: ",
" - debian/patches/CVE-2026-42012-pre1.patch: x509/hostname-verify: refactor",
" and simplify CN fallback logic in lib/x509/hostname-verify.c.",
" - debian/patches/CVE-2026-42012-pre2.patch: x509: add bare-bones awareness",
" of SRV virtual SAN in lib/includes/gnutls/gnutls.h.in, lib/x509/common.h,",
" lib/x509/name_constraints.c, lib/x509/output.c, lib/x509/virt-san.c,",
" lib/x509/x509.c.",
" - debian/patches/CVE-2026-42012.patch: x509/hostname-verify: make URI/SRV",
" SAN preclude CN fallback in lib/x509/hostname-verify.c.",
" - CVE-2026-42012",
" * SECURITY UPDATE: incorrect URI or SRV Subject Alternative Names checking",
" - debian/patches/CVE-2026-42013-pre1.patch: x509/email-verify: call",
" fallback DN fallback in lib/x509/email-verify.c.",
" - debian/patches/CVE-2026-42013.patch: x509: prevent fallback on oversized",
" SAN in lib/x509/email-verify.c, lib/x509/hostname-verify.c.",
" - CVE-2026-42013",
" * SECURITY UPDATE: UaF when changing the Security Officer PIN",
" - debian/patches/CVE-2026-42014.patch: pkcs11_write: fix UAF and leak in",
" gnutls_pkcs11_token_set_pin in lib/pkcs11_write.c.",
" - CVE-2026-42014",
" * SECURITY UPDATE: buffer overflow when appending to a PKCS#12 bag",
" - debian/patches/CVE-2026-42015.patch: x509/pkcs12_bag: fix off-by-one in",
" bag element bounds check in lib/x509/pkcs12_bag.c.",
" - CVE-2026-42015",
" * SECURITY UPDATE: non constant-time PKCS#7 padding check",
" - debian/patches/CVE-2026-5419.patch: gnutls_cipher_decrypt3: make PKCS#7",
" unpadding branch free in lib/crypto-api.c, lib/libgnutls.map,",
" tests/Makefile.am, tests/pkcs7-pad.c.",
" - debian/patches/CVE-2026-5419-2.patch: _gnutls_pkcs7_unpad: add missing",
" declaration in lib/crypto-api.c.",
" - CVE-2026-5419",
""
],
"package": "gnutls28",
"version": "3.8.9-3ubuntu2.2",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Fri, 08 May 2026 11:40:52 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libkmod2",
"from_version": {
"source_package_name": "kmod",
"source_package_version": "34.2-2ubuntu1",
"version": "34.2-2ubuntu1"
},
"to_version": {
"source_package_name": "kmod",
"source_package_version": "34.2-2ubuntu1.1",
"version": "34.2-2ubuntu1.1"
},
"cves": [
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2150743
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
}
],
"log": [
"",
" * Disable loading of algif_aead module to mitigate CVE-2026-31431",
" (LP: #2150743)",
" - debian/modprobe.d/disable-algif_aead.conf",
""
],
"package": "kmod",
"version": "34.2-2ubuntu1.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [
2150743
],
"author": "Marc Deslauriers ",
"date": "Thu, 30 Apr 2026 08:31:34 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libnghttp2-14",
"from_version": {
"source_package_name": "nghttp2",
"source_package_version": "1.64.0-1.1ubuntu1",
"version": "1.64.0-1.1ubuntu1"
},
"to_version": {
"source_package_name": "nghttp2",
"source_package_version": "1.64.0-1.1ubuntu1.1",
"version": "1.64.0-1.1ubuntu1.1"
},
"cves": [
{
"cve": "CVE-2026-27135",
"url": "https://ubuntu.com/security/CVE-2026-27135",
"cve_description": "nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.",
"cve_priority": "medium",
"cve_public_date": "2026-03-18 18:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-27135",
"url": "https://ubuntu.com/security/CVE-2026-27135",
"cve_description": "nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. Prior to version 1.68.1, the nghttp2 library stops reading the incoming data when user facing public API `nghttp2_session_terminate_session` or `nghttp2_session_terminate_session2` is called by the application. They might be called internally by the library when it detects the situation that is subject to connection error. Due to the missing internal state validation, the library keeps reading the rest of the data after one of those APIs is called. Then receiving a malformed frame that causes FRAME_SIZE_ERROR causes assertion failure. nghttp2 v1.68.1 adds missing state validation to avoid assertion failure. No known workarounds are available.",
"cve_priority": "medium",
"cve_public_date": "2026-03-18 18:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Denial of service through assertion failure.",
" - debian/patches/CVE-2026-27135-pre1.patch: Add iframe->state ==",
" NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.",
" - debian/patches/CVE-2026-27135-pre2.patch: Add iframe->state ==",
" NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.",
" - debian/patches/CVE-2026-27135.patch: Add iframe->state ==",
" NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.",
" - debian/patches/CVE-2026-27135-post1.patch: Add iframe->state ==",
" NGHTTP2_IB_IGN_ALL checks in lib/nghttp2_session.c.",
" - CVE-2026-27135",
""
],
"package": "nghttp2",
"version": "1.64.0-1.1ubuntu1.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Hlib Korzhynskyy ",
"date": "Thu, 23 Apr 2026 16:13:11 -0230"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "libpng16-16t64",
"from_version": {
"source_package_name": "libpng1.6",
"source_package_version": "1.6.50-1ubuntu0.4",
"version": "1.6.50-1ubuntu0.4"
},
"to_version": {
"source_package_name": "libpng1.6",
"source_package_version": "1.6.50-1ubuntu0.5",
"version": "1.6.50-1ubuntu0.5"
},
"cves": [
{
"cve": "CVE-2026-33416",
"url": "https://ubuntu.com/security/CVE-2026-33416",
"cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr->trans_alpha = info_ptr->trans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr->palette = png_ptr->palette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue.",
"cve_priority": "medium",
"cve_public_date": "2026-03-26 17:16:00 UTC"
},
{
"cve": "CVE-2026-33636",
"url": "https://ubuntu.com/security/CVE-2026-33636",
"cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.6.36 through 1.6.55, an out-of-bounds read and write exists in libpng's ARM/AArch64 Neon-optimized palette expansion path. When expanding 8-bit paletted rows to RGB or RGBA, the Neon loop processes a final partial chunk without verifying that enough input pixels remain. Because the implementation works backward from the end of the row, the final iteration dereferences pointers before the start of the row buffer (OOB read) and writes expanded pixel data to the same underflowed positions (OOB write). This is reachable via normal decoding of attacker-controlled PNG input if Neon is enabled. Version 1.6.56 fixes the issue.",
"cve_priority": "medium",
"cve_public_date": "2026-03-26 17:16:00 UTC"
},
{
"cve": "CVE-2026-34757",
"url": "https://ubuntu.com/security/CVE-2026-34757",
"cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.",
"cve_priority": "medium",
"cve_public_date": "2026-04-09 15:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-33416",
"url": "https://ubuntu.com/security/CVE-2026-33416",
"cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.2.1 through 1.6.55, `png_set_tRNS` and `png_set_PLTE` each alias a heap-allocated buffer between `png_struct` and `png_info`, sharing a single allocation across two structs with independent lifetimes. The `trans_alpha` aliasing has been present since at least libpng 1.0, and the `palette` aliasing since at least 1.2.1. Both affect all prior release lines `png_set_tRNS` sets `png_ptr->trans_alpha = info_ptr->trans_alpha` (256-byte buffer) and `png_set_PLTE` sets `info_ptr->palette = png_ptr->palette` (768-byte buffer). In both cases, calling `png_free_data` (with `PNG_FREE_TRNS` or `PNG_FREE_PLTE`) frees the buffer through `info_ptr` while the corresponding `png_ptr` pointer remains dangling. Subsequent row-transform functions dereference and, in some code paths, write to the freed memory. A second call to `png_set_tRNS` or `png_set_PLTE` has the same effect, because both functions call `png_free_data` internally before reallocating the `info_ptr` buffer. Version 1.6.56 fixes the issue.",
"cve_priority": "medium",
"cve_public_date": "2026-03-26 17:16:00 UTC"
},
{
"cve": "CVE-2026-33636",
"url": "https://ubuntu.com/security/CVE-2026-33636",
"cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. In versions 1.6.36 through 1.6.55, an out-of-bounds read and write exists in libpng's ARM/AArch64 Neon-optimized palette expansion path. When expanding 8-bit paletted rows to RGB or RGBA, the Neon loop processes a final partial chunk without verifying that enough input pixels remain. Because the implementation works backward from the end of the row, the final iteration dereferences pointers before the start of the row buffer (OOB read) and writes expanded pixel data to the same underflowed positions (OOB write). This is reachable via normal decoding of attacker-controlled PNG input if Neon is enabled. Version 1.6.56 fixes the issue.",
"cve_priority": "medium",
"cve_public_date": "2026-03-26 17:16:00 UTC"
},
{
"cve": "CVE-2026-34757",
"url": "https://ubuntu.com/security/CVE-2026-34757",
"cve_description": "LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.0.9 to before 1.6.57, passing a pointer obtained from png_get_PLTE, png_get_tRNS, or png_get_hIST back into the corresponding setter on the same png_struct/png_info pair causes the setter to read from freed memory and copy its contents into the replacement buffer. The setter frees the internal buffer before copying from the caller-supplied pointer, which now dangles. The freed region may contain stale data (producing silently corrupted chunk metadata) or data from subsequent heap allocations (leaking unrelated heap contents into the chunk struct). This vulnerability is fixed in 1.6.57.",
"cve_priority": "medium",
"cve_public_date": "2026-04-09 15:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: use-after-free via shared buffers",
" - debian/patches/CVE-2026-33416-1.patch: fix: Resolve use-after-free on",
" `png_ptr->trans_alpha` in pngread.c, pngrutil.c, pngset.c, pngwrite.c.",
" - debian/patches/CVE-2026-33416-2.patch: fix: Resolve use-after-free on",
" `png_ptr->palette` in pngread.c, pngrtran.c, pngrutil.c, pngset.c,",
" pngwrite.c.",
" - debian/patches/CVE-2026-33416-3.patch: fix: Initialize tail bytes in",
" `trans_alpha` buffers in pngset.c.",
" - debian/patches/CVE-2026-33416-4.patch: fix: Sync `info_ptr->palette` after",
" in-place transforms in pngrtran.c.",
" - debian/patches/CVE-2026-33416-5.patch: fix: Sync `info_ptr->palette`",
" unconditionally after in-place transforms in pngrtran.c.",
" - CVE-2026-33416",
" * SECURITY UPDATE: out-of-bounds access in ARM palette expansion path",
" - debian/patches/CVE-2026-33636.patch: fix(arm): Resolve out-of-bounds",
" read/write in NEON palette expansion in arm/palette_neon_intrinsics.c.",
" - CVE-2026-33636",
" * SECURITY UPDATE: getter-to-setter aliasing issues",
" - debian/patches/CVE-2026-34757-1.patch: fix: Handle self-referencing",
" pointers in getter-to-setter aliasing in CMakeLists.txt, Makefile.am,",
" contrib/libtests/pnggetset.c, pngset.c, tests/pnggetset.",
" - debian/patches/CVE-2026-34757-2.patch: fix: Handle getter-to-setter",
" aliasing in append-style chunk setters in contrib/libtests/pnggetset.c,",
" pngset.c.",
" - CVE-2026-34757",
" * SECURITY UPDATE: integer overflow in rowbytes computation",
" - debian/patches/rowbytes_overflow.patch: fix: Prevent integer overflow in",
" rowbytes computation in AUTHORS, pngrtran.c.",
" - No CVE number",
""
],
"package": "libpng1.6",
"version": "1.6.50-1ubuntu0.5",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Tue, 05 May 2026 14:55:25 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-headers-generic",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-29.29",
""
],
"package": "linux-meta",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:54 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-28.28",
""
],
"package": "linux-meta",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:21:59 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-26.26",
""
],
"package": "linux-meta",
"version": "6.17.0-26.26",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Wed, 22 Apr 2026 22:03:41 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-24.24",
""
],
"package": "linux-meta",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:27:41 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-headers-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-29.29",
""
],
"package": "linux-meta",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:54 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-28.28",
""
],
"package": "linux-meta",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:21:59 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-26.26",
""
],
"package": "linux-meta",
"version": "6.17.0-26.26",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Wed, 22 Apr 2026 22:03:41 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-24.24",
""
],
"package": "linux-meta",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:27:41 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-image-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-29.29",
""
],
"package": "linux-meta",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:54 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-28.28",
""
],
"package": "linux-meta",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:21:59 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-26.26",
""
],
"package": "linux-meta",
"version": "6.17.0-26.26",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Wed, 22 Apr 2026 22:03:41 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-24.24",
""
],
"package": "linux-meta",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:27:41 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-libc-dev",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-perf",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-tools-common",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-virtual",
"from_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": "linux-meta",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-29.29",
""
],
"package": "linux-meta",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:54 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-28.28",
""
],
"package": "linux-meta",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:21:59 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-26.26",
""
],
"package": "linux-meta",
"version": "6.17.0-26.26",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Wed, 22 Apr 2026 22:03:41 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-24.24",
""
],
"package": "linux-meta",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:27:41 +0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "openssh-client",
"from_version": {
"source_package_name": "openssh",
"source_package_version": "1:10.0p1-5ubuntu5.1",
"version": "1:10.0p1-5ubuntu5.1"
},
"to_version": {
"source_package_name": "openssh",
"source_package_version": "1:10.0p1-5ubuntu5.4",
"version": "1:10.0p1-5ubuntu5.4"
},
"cves": [
{
"cve": "CVE-2026-35385",
"url": "https://ubuntu.com/security/CVE-2026-35385",
"cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35386",
"url": "https://ubuntu.com/security/CVE-2026-35386",
"cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35387",
"url": "https://ubuntu.com/security/CVE-2026-35387",
"cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35388",
"url": "https://ubuntu.com/security/CVE-2026-35388",
"cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35414",
"url": "https://ubuntu.com/security/CVE-2026-35414",
"cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 18:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2147451
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-35385",
"url": "https://ubuntu.com/security/CVE-2026-35385",
"cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35386",
"url": "https://ubuntu.com/security/CVE-2026-35386",
"cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35387",
"url": "https://ubuntu.com/security/CVE-2026-35387",
"cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35388",
"url": "https://ubuntu.com/security/CVE-2026-35388",
"cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35414",
"url": "https://ubuntu.com/security/CVE-2026-35414",
"cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 18:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: unexpected scp setuid and setgid",
" - debian/patches/CVE-2026-35385.patch: clear setuid/setgid bits from",
" downloaded files in scp.c.",
" - CVE-2026-35385",
" * SECURITY UPDATE: command execution via shell metacharacters in username",
" - debian/patches/CVE-2026-35386-pre1.patch: apply validity rules on",
" ProxyJump usernames and hostnames in readconf.c, readconf.h, ssh.c.",
" - debian/patches/CVE-2026-35386.patch: move username check earlier in",
" ssh.c.",
" - debian/patches/CVE-2026-35386-2.patch: adapt to username validity",
" check change in regress/percent.sh.",
" - CVE-2026-35386",
" * SECURITY UPDATE: use of unintended ECDSA algorithms",
" - debian/patches/CVE-2026-35387_35414.patch: correctly match ECDSA",
" signature algorithms against algorithm allowlists in",
" auth2-hostbased.c, auth2-pubkey.c, sshconnect2.c.",
" - CVE-2026-35387",
" * SECURITY UPDATE: missing connection multiplexing confirmation",
" - debian/patches/CVE-2026-35388.patch: add missing askpass check in",
" mux.c.",
" - CVE-2026-35388",
" * SECURITY UPDATE: authorized_keys principals option mishandling",
" - debian/patches/CVE-2026-35387_35414.patch: check for commas in",
" auth2-pubkeyfile.c.",
" - CVE-2026-35414",
""
],
"package": "openssh",
"version": "1:10.0p1-5ubuntu5.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Mon, 27 Apr 2026 20:24:02 -0400"
},
{
"cves": [],
"log": [
"",
" * repair test after changes to percent expansion of usernames",
" (LP: #2147451)",
""
],
"package": "openssh",
"version": "1:10.0p1-5ubuntu5.2",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2147451
],
"author": "Nick Rosbrook ",
"date": "Tue, 07 Apr 2026 10:00:59 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "openssh-server",
"from_version": {
"source_package_name": "openssh",
"source_package_version": "1:10.0p1-5ubuntu5.1",
"version": "1:10.0p1-5ubuntu5.1"
},
"to_version": {
"source_package_name": "openssh",
"source_package_version": "1:10.0p1-5ubuntu5.4",
"version": "1:10.0p1-5ubuntu5.4"
},
"cves": [
{
"cve": "CVE-2026-35385",
"url": "https://ubuntu.com/security/CVE-2026-35385",
"cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35386",
"url": "https://ubuntu.com/security/CVE-2026-35386",
"cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35387",
"url": "https://ubuntu.com/security/CVE-2026-35387",
"cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35388",
"url": "https://ubuntu.com/security/CVE-2026-35388",
"cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35414",
"url": "https://ubuntu.com/security/CVE-2026-35414",
"cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 18:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2147451
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-35385",
"url": "https://ubuntu.com/security/CVE-2026-35385",
"cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35386",
"url": "https://ubuntu.com/security/CVE-2026-35386",
"cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35387",
"url": "https://ubuntu.com/security/CVE-2026-35387",
"cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35388",
"url": "https://ubuntu.com/security/CVE-2026-35388",
"cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35414",
"url": "https://ubuntu.com/security/CVE-2026-35414",
"cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 18:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: unexpected scp setuid and setgid",
" - debian/patches/CVE-2026-35385.patch: clear setuid/setgid bits from",
" downloaded files in scp.c.",
" - CVE-2026-35385",
" * SECURITY UPDATE: command execution via shell metacharacters in username",
" - debian/patches/CVE-2026-35386-pre1.patch: apply validity rules on",
" ProxyJump usernames and hostnames in readconf.c, readconf.h, ssh.c.",
" - debian/patches/CVE-2026-35386.patch: move username check earlier in",
" ssh.c.",
" - debian/patches/CVE-2026-35386-2.patch: adapt to username validity",
" check change in regress/percent.sh.",
" - CVE-2026-35386",
" * SECURITY UPDATE: use of unintended ECDSA algorithms",
" - debian/patches/CVE-2026-35387_35414.patch: correctly match ECDSA",
" signature algorithms against algorithm allowlists in",
" auth2-hostbased.c, auth2-pubkey.c, sshconnect2.c.",
" - CVE-2026-35387",
" * SECURITY UPDATE: missing connection multiplexing confirmation",
" - debian/patches/CVE-2026-35388.patch: add missing askpass check in",
" mux.c.",
" - CVE-2026-35388",
" * SECURITY UPDATE: authorized_keys principals option mishandling",
" - debian/patches/CVE-2026-35387_35414.patch: check for commas in",
" auth2-pubkeyfile.c.",
" - CVE-2026-35414",
""
],
"package": "openssh",
"version": "1:10.0p1-5ubuntu5.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Mon, 27 Apr 2026 20:24:02 -0400"
},
{
"cves": [],
"log": [
"",
" * repair test after changes to percent expansion of usernames",
" (LP: #2147451)",
""
],
"package": "openssh",
"version": "1:10.0p1-5ubuntu5.2",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2147451
],
"author": "Nick Rosbrook ",
"date": "Tue, 07 Apr 2026 10:00:59 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "openssh-sftp-server",
"from_version": {
"source_package_name": "openssh",
"source_package_version": "1:10.0p1-5ubuntu5.1",
"version": "1:10.0p1-5ubuntu5.1"
},
"to_version": {
"source_package_name": "openssh",
"source_package_version": "1:10.0p1-5ubuntu5.4",
"version": "1:10.0p1-5ubuntu5.4"
},
"cves": [
{
"cve": "CVE-2026-35385",
"url": "https://ubuntu.com/security/CVE-2026-35385",
"cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35386",
"url": "https://ubuntu.com/security/CVE-2026-35386",
"cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35387",
"url": "https://ubuntu.com/security/CVE-2026-35387",
"cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35388",
"url": "https://ubuntu.com/security/CVE-2026-35388",
"cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35414",
"url": "https://ubuntu.com/security/CVE-2026-35414",
"cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 18:16:00 UTC"
}
],
"launchpad_bugs_fixed": [
2147451
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-35385",
"url": "https://ubuntu.com/security/CVE-2026-35385",
"cve_description": "In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35386",
"url": "https://ubuntu.com/security/CVE-2026-35386",
"cve_description": "In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in ssh_config.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35387",
"url": "https://ubuntu.com/security/CVE-2026-35387",
"cve_description": "OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35388",
"url": "https://ubuntu.com/security/CVE-2026-35388",
"cve_description": "OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 17:16:00 UTC"
},
{
"cve": "CVE-2026-35414",
"url": "https://ubuntu.com/security/CVE-2026-35414",
"cve_description": "OpenSSH before 10.3 mishandles the authorized_keys principals option in uncommon scenarios involving a principals list in conjunction with a Certificate Authority that makes certain use of comma characters.",
"cve_priority": "medium",
"cve_public_date": "2026-04-02 18:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: unexpected scp setuid and setgid",
" - debian/patches/CVE-2026-35385.patch: clear setuid/setgid bits from",
" downloaded files in scp.c.",
" - CVE-2026-35385",
" * SECURITY UPDATE: command execution via shell metacharacters in username",
" - debian/patches/CVE-2026-35386-pre1.patch: apply validity rules on",
" ProxyJump usernames and hostnames in readconf.c, readconf.h, ssh.c.",
" - debian/patches/CVE-2026-35386.patch: move username check earlier in",
" ssh.c.",
" - debian/patches/CVE-2026-35386-2.patch: adapt to username validity",
" check change in regress/percent.sh.",
" - CVE-2026-35386",
" * SECURITY UPDATE: use of unintended ECDSA algorithms",
" - debian/patches/CVE-2026-35387_35414.patch: correctly match ECDSA",
" signature algorithms against algorithm allowlists in",
" auth2-hostbased.c, auth2-pubkey.c, sshconnect2.c.",
" - CVE-2026-35387",
" * SECURITY UPDATE: missing connection multiplexing confirmation",
" - debian/patches/CVE-2026-35388.patch: add missing askpass check in",
" mux.c.",
" - CVE-2026-35388",
" * SECURITY UPDATE: authorized_keys principals option mishandling",
" - debian/patches/CVE-2026-35387_35414.patch: check for commas in",
" auth2-pubkeyfile.c.",
" - CVE-2026-35414",
""
],
"package": "openssh",
"version": "1:10.0p1-5ubuntu5.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Mon, 27 Apr 2026 20:24:02 -0400"
},
{
"cves": [],
"log": [
"",
" * repair test after changes to percent expansion of usernames",
" (LP: #2147451)",
""
],
"package": "openssh",
"version": "1:10.0p1-5ubuntu5.2",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2147451
],
"author": "Nick Rosbrook ",
"date": "Tue, 07 Apr 2026 10:00:59 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "python3-distupgrade",
"from_version": {
"source_package_name": "ubuntu-release-upgrader",
"source_package_version": "1:25.10.9",
"version": "1:25.10.9"
},
"to_version": {
"source_package_name": "ubuntu-release-upgrader",
"source_package_version": "1:25.10.10",
"version": "1:25.10.10"
},
"cves": [],
"launchpad_bugs_fixed": [
2125687
],
"changes": [
{
"cves": [],
"log": [
"",
" * DistUpgradeFetcherCore: use gpgv to verify signatures (LP: #2125687)",
""
],
"package": "ubuntu-release-upgrader",
"version": "1:25.10.10",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2125687
],
"author": "Simon Poirier ",
"date": "Fri, 17 Apr 2026 13:04:46 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "rsync",
"from_version": {
"source_package_name": "rsync",
"source_package_version": "3.4.1+ds1-5ubuntu1",
"version": "3.4.1+ds1-5ubuntu1"
},
"to_version": {
"source_package_name": "rsync",
"source_package_version": "3.4.1+ds1-5ubuntu1.2",
"version": "3.4.1+ds1-5ubuntu1.2"
},
"cves": [
{
"cve": "CVE-2025-10158",
"url": "https://ubuntu.com/security/CVE-2025-10158",
"cve_description": "A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The malicious rsync client requires at least read access to the remote rsync module in order to trigger the issue.",
"cve_priority": "low",
"cve_public_date": "2025-11-18 15:16:00 UTC"
},
{
"cve": "CVE-2026-29518",
"url": "https://ubuntu.com/security/CVE-2026-29518",
"cve_description": "An rsync daemon configured with \"use chroot = no\" is exposed to a time-of-check / time-of-use race on parent path components. A local attacker with write access to a module can replace a parent directory component with a symlink between the receiver's check and its open(), redirecting reads (basis-file disclosure) and writes (file overwrite) outside the module. Under elevated daemon privilege this allows privilege escalation. Default \"use chroot = yes\" is not exposed.",
"cve_priority": "high",
"cve_public_date": "2026-05-20 00:00:00 UTC"
},
{
"cve": "CVE-2026-41035",
"url": "https://ubuntu.com/security/CVE-2026-41035",
"cve_description": "In rsync 3.0.1 through 3.4.1, receive_xattr relies on an untrusted length value during a qsort call, leading to a receiver use-after-free. The victim must run rsync with -X (aka --xattrs). On Linux, many (but not all) common configurations are vulnerable. Non-Linux platforms are more widely vulnerable.",
"cve_priority": "low",
"cve_public_date": "2026-04-16 07:16:00 UTC"
},
{
"cve": "CVE-2026-43617",
"url": "https://ubuntu.com/security/CVE-2026-43617",
"cve_description": "Rsync version 3.4.2 and prior contain an authorization bypass vulnerability in the rsync daemon's hostname-based access control list enforcement when configured with chroot. Attackers can bypass hostname-based deny rules by controlling the PTR record for their source IP address, allowing connections from hostnames that administrators intended to deny when reverse DNS resolution fails and defaults to UNKNOWN.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-43618",
"url": "https://ubuntu.com/security/CVE-2026-43618",
"cve_description": "Rsync version 3.4.2 and prior contain an integer overflow vulnerability in the compressed-token decoder where a 32-bit signed counter is not checked for overflow, allowing a malicious sender to trigger an overflow that causes the receiver process to read and return data from outside the intended buffer bounds. Attackers can exploit this vulnerability to disclose process memory contents including environment variables, passwords, heap and stack data, and library memory pointers, significantly reducing ASLR effectiveness and facilitating further exploitation.",
"cve_priority": "high",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-43619",
"url": "https://ubuntu.com/security/CVE-2026-43619",
"cve_description": "Rsync version 3.4.2 and prior contain symlink race condition vulnerabilities in path-based system calls including chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir, and lstat that allow local attackers to redirect operations to files outside the exported rsync module. Attackers with local filesystem access can exploit the timing window between path resolution and syscall execution by swapping symlinks to apply sender-supplied permissions, ownership, timestamps, or filenames to arbitrary files outside the intended module boundary on rsync daemons configured with 'use chroot = no'.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-43620",
"url": "https://ubuntu.com/security/CVE-2026-43620",
"cve_description": "Rsync version 3.4.2 and prior contain a receiver-side out-of-bounds array read vulnerability in recv_files() in receiver.c that allows a malicious rsync server to crash the rsync client process. Attackers can exploit the vulnerability by setting CF_INC_RECURSE in compatibility flags and sending a specially crafted file list where the first sorted entry is not the leading dot directory, followed by a transfer record with ndx=0 and an iflag word without ITEM_TRANSFER, causing the receiver to read 8 bytes before the allocated pointer array and dereference an invalid pointer at an unmapped address, resulting in a deterministic SIGSEGV crash of the rsync client.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-45232",
"url": "https://ubuntu.com/security/CVE-2026-45232",
"cve_description": "Rsync versions before 3.4.3 contain an off-by-one out-of-bounds stack write vulnerability in the establish_proxy_connection() function in socket.c that allows network attackers to corrupt stack memory by sending a malformed HTTP proxy response. Attackers can exploit this by positioning themselves between the client and proxy or controlling the proxy server to send a response line of 1023 or more bytes without a newline terminator, causing a null byte to be written to an out-of-bounds stack address when the RSYNC_PROXY environment variable is set.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2025-10158",
"url": "https://ubuntu.com/security/CVE-2025-10158",
"cve_description": "A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The malicious rsync client requires at least read access to the remote rsync module in order to trigger the issue.",
"cve_priority": "low",
"cve_public_date": "2025-11-18 15:16:00 UTC"
},
{
"cve": "CVE-2026-29518",
"url": "https://ubuntu.com/security/CVE-2026-29518",
"cve_description": "An rsync daemon configured with \"use chroot = no\" is exposed to a time-of-check / time-of-use race on parent path components. A local attacker with write access to a module can replace a parent directory component with a symlink between the receiver's check and its open(), redirecting reads (basis-file disclosure) and writes (file overwrite) outside the module. Under elevated daemon privilege this allows privilege escalation. Default \"use chroot = yes\" is not exposed.",
"cve_priority": "high",
"cve_public_date": "2026-05-20 00:00:00 UTC"
},
{
"cve": "CVE-2026-41035",
"url": "https://ubuntu.com/security/CVE-2026-41035",
"cve_description": "In rsync 3.0.1 through 3.4.1, receive_xattr relies on an untrusted length value during a qsort call, leading to a receiver use-after-free. The victim must run rsync with -X (aka --xattrs). On Linux, many (but not all) common configurations are vulnerable. Non-Linux platforms are more widely vulnerable.",
"cve_priority": "low",
"cve_public_date": "2026-04-16 07:16:00 UTC"
},
{
"cve": "CVE-2026-43617",
"url": "https://ubuntu.com/security/CVE-2026-43617",
"cve_description": "Rsync version 3.4.2 and prior contain an authorization bypass vulnerability in the rsync daemon's hostname-based access control list enforcement when configured with chroot. Attackers can bypass hostname-based deny rules by controlling the PTR record for their source IP address, allowing connections from hostnames that administrators intended to deny when reverse DNS resolution fails and defaults to UNKNOWN.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-43618",
"url": "https://ubuntu.com/security/CVE-2026-43618",
"cve_description": "Rsync version 3.4.2 and prior contain an integer overflow vulnerability in the compressed-token decoder where a 32-bit signed counter is not checked for overflow, allowing a malicious sender to trigger an overflow that causes the receiver process to read and return data from outside the intended buffer bounds. Attackers can exploit this vulnerability to disclose process memory contents including environment variables, passwords, heap and stack data, and library memory pointers, significantly reducing ASLR effectiveness and facilitating further exploitation.",
"cve_priority": "high",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-43619",
"url": "https://ubuntu.com/security/CVE-2026-43619",
"cve_description": "Rsync version 3.4.2 and prior contain symlink race condition vulnerabilities in path-based system calls including chmod, lchown, utimes, rename, unlink, mkdir, symlink, mknod, link, rmdir, and lstat that allow local attackers to redirect operations to files outside the exported rsync module. Attackers with local filesystem access can exploit the timing window between path resolution and syscall execution by swapping symlinks to apply sender-supplied permissions, ownership, timestamps, or filenames to arbitrary files outside the intended module boundary on rsync daemons configured with 'use chroot = no'.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-43620",
"url": "https://ubuntu.com/security/CVE-2026-43620",
"cve_description": "Rsync version 3.4.2 and prior contain a receiver-side out-of-bounds array read vulnerability in recv_files() in receiver.c that allows a malicious rsync server to crash the rsync client process. Attackers can exploit the vulnerability by setting CF_INC_RECURSE in compatibility flags and sending a specially crafted file list where the first sorted entry is not the leading dot directory, followed by a transfer record with ndx=0 and an iflag word without ITEM_TRANSFER, causing the receiver to read 8 bytes before the allocated pointer array and dereference an invalid pointer at an unmapped address, resulting in a deterministic SIGSEGV crash of the rsync client.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
},
{
"cve": "CVE-2026-45232",
"url": "https://ubuntu.com/security/CVE-2026-45232",
"cve_description": "Rsync versions before 3.4.3 contain an off-by-one out-of-bounds stack write vulnerability in the establish_proxy_connection() function in socket.c that allows network attackers to corrupt stack memory by sending a malformed HTTP proxy response. Attackers can exploit this by positioning themselves between the client and proxy or controlling the proxy server to send a response line of 1023 or more bytes without a newline terminator, causing a null byte to be written to an out-of-bounds stack address when the RSYNC_PROXY environment variable is set.",
"cve_priority": "medium",
"cve_public_date": "2026-05-20 02:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: May 2026 security issues",
" - debian/patches/security-202605/*.patch: commits to backport security",
" fixes to 3.4.1.",
" - d/p/do-not-typedef-bool.patch: removed, included in patch cluster.",
" - d/p/fix-flaky-hardlinks-test.patch: removed, included in patch",
" cluster.",
" - CVE-2025-10158",
" - CVE-2026-29518",
" - CVE-2026-41035",
" - CVE-2026-43617",
" - CVE-2026-43618",
" - CVE-2026-43619",
" - CVE-2026-43620",
" - CVE-2026-45232",
""
],
"package": "rsync",
"version": "3.4.1+ds1-5ubuntu1.2",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Thu, 14 May 2026 10:58:37 +0200"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "sed",
"from_version": {
"source_package_name": "sed",
"source_package_version": "4.9-2build2",
"version": "4.9-2build2"
},
"to_version": {
"source_package_name": "sed",
"source_package_version": "4.9-2ubuntu0.25.10.1",
"version": "4.9-2ubuntu0.25.10.1"
},
"cves": [
{
"cve": "CVE-2026-5958",
"url": "https://ubuntu.com/security/CVE-2026-5958",
"cve_description": "When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written, 2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process. This issue was fixed in version 4.10.",
"cve_priority": "medium",
"cve_public_date": "2026-04-20 12:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-5958",
"url": "https://ubuntu.com/security/CVE-2026-5958",
"cve_description": "When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path: 1. resolves symlink to its target and stores the resolved path for determining when output is written, 2. opens the original symlink path (not the resolved one) to read the file. Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process. This issue was fixed in version 4.10.",
"cve_priority": "medium",
"cve_public_date": "2026-04-20 12:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: TOCTOU race in sed -i --follow-symlinks",
" - debian/patches/CVE-2026-5958.patch: open the already-resolved path",
" instead of re-traversing the symlink in sed/execute.c.",
" - CVE-2026-5958",
""
],
"package": "sed",
"version": "4.9-2ubuntu0.25.10.1",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Marc Deslauriers ",
"date": "Fri, 17 Apr 2026 14:01:27 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "ubuntu-release-upgrader-core",
"from_version": {
"source_package_name": "ubuntu-release-upgrader",
"source_package_version": "1:25.10.9",
"version": "1:25.10.9"
},
"to_version": {
"source_package_name": "ubuntu-release-upgrader",
"source_package_version": "1:25.10.10",
"version": "1:25.10.10"
},
"cves": [],
"launchpad_bugs_fixed": [
2125687
],
"changes": [
{
"cves": [],
"log": [
"",
" * DistUpgradeFetcherCore: use gpgv to verify signatures (LP: #2125687)",
""
],
"package": "ubuntu-release-upgrader",
"version": "1:25.10.10",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2125687
],
"author": "Simon Poirier ",
"date": "Fri, 17 Apr 2026 13:04:46 -0400"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.3",
"version": "2:9.1.0967-1ubuntu6.3"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.4",
"version": "2:9.1.0967-1ubuntu6.4"
},
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Command injection via backtick expansion in tag files",
" - debian/patches/CVE-2026-41411.patch: Disallow backticks before attempting",
" to expand filenames",
" - CVE-2026-41411",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Federico Quattrin ",
"date": "Tue, 05 May 2026 06:12:13 -0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim-common",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.3",
"version": "2:9.1.0967-1ubuntu6.3"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.4",
"version": "2:9.1.0967-1ubuntu6.4"
},
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Command injection via backtick expansion in tag files",
" - debian/patches/CVE-2026-41411.patch: Disallow backticks before attempting",
" to expand filenames",
" - CVE-2026-41411",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Federico Quattrin ",
"date": "Tue, 05 May 2026 06:12:13 -0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim-runtime",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.3",
"version": "2:9.1.0967-1ubuntu6.3"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.4",
"version": "2:9.1.0967-1ubuntu6.4"
},
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Command injection via backtick expansion in tag files",
" - debian/patches/CVE-2026-41411.patch: Disallow backticks before attempting",
" to expand filenames",
" - CVE-2026-41411",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Federico Quattrin ",
"date": "Tue, 05 May 2026 06:12:13 -0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "vim-tiny",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.3",
"version": "2:9.1.0967-1ubuntu6.3"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.4",
"version": "2:9.1.0967-1ubuntu6.4"
},
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Command injection via backtick expansion in tag files",
" - debian/patches/CVE-2026-41411.patch: Disallow backticks before attempting",
" to expand filenames",
" - CVE-2026-41411",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Federico Quattrin ",
"date": "Tue, 05 May 2026 06:12:13 -0300"
}
],
"notes": null,
"is_version_downgrade": false
},
{
"name": "xxd",
"from_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.3",
"version": "2:9.1.0967-1ubuntu6.3"
},
"to_version": {
"source_package_name": "vim",
"source_package_version": "2:9.1.0967-1ubuntu6.4",
"version": "2:9.1.0967-1ubuntu6.4"
},
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"launchpad_bugs_fixed": [],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-41411",
"url": "https://ubuntu.com/security/CVE-2026-41411",
"cve_description": "Vim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user.",
"cve_priority": "medium",
"cve_public_date": "2026-04-24 17:16:00 UTC"
}
],
"log": [
"",
" * SECURITY UPDATE: Command injection via backtick expansion in tag files",
" - debian/patches/CVE-2026-41411.patch: Disallow backticks before attempting",
" to expand filenames",
" - CVE-2026-41411",
""
],
"package": "vim",
"version": "2:9.1.0967-1ubuntu6.4",
"urgency": "medium",
"distributions": "questing-security",
"launchpad_bugs_fixed": [],
"author": "Federico Quattrin ",
"date": "Tue, 05 May 2026 06:12:13 -0300"
}
],
"notes": null,
"is_version_downgrade": false
}
],
"snap": []
},
"added": {
"deb": [
{
"name": "linux-headers-6.17.0-29",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": "linux-headers-6.17.0-29 version '6.17.0-29.29' (source package linux version '6.17.0-29.29') was added. linux-headers-6.17.0-29 version '6.17.0-29.29' has the same source package name, linux, as removed package linux-headers-6.17.0-22. As such we can use the source package version of the removed package, '6.17.0-22.22', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
},
{
"name": "linux-headers-6.17.0-29-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": "linux-headers-6.17.0-29-generic version '6.17.0-29.29' (source package linux version '6.17.0-29.29') was added. linux-headers-6.17.0-29-generic version '6.17.0-29.29' has the same source package name, linux, as removed package linux-headers-6.17.0-22. As such we can use the source package version of the removed package, '6.17.0-22.22', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
},
{
"name": "linux-image-6.17.0-29-generic",
"from_version": {
"source_package_name": "linux-signed",
"source_package_version": "6.17.0-22.22",
"version": null
},
"to_version": {
"source_package_name": "linux-signed",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [],
"launchpad_bugs_fixed": [
1786013,
1786013,
1786013
],
"changes": [
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-29.29",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:54:02 +0200"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-28.28",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:22:17 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-26.26",
""
],
"package": "linux-signed",
"version": "6.17.0-26.26",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [],
"author": "Mehmet Basaran ",
"date": "Wed, 22 Apr 2026 22:04:03 +0300"
},
{
"cves": [],
"log": [
"",
" * Main version: 6.17.0-24.24",
"",
" * Packaging resync (LP: #1786013)",
" - [Packaging] debian/tracking-bug -- resync from main package",
""
],
"package": "linux-signed",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
1786013
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:28:00 +0300"
}
],
"notes": "linux-image-6.17.0-29-generic version '6.17.0-29.29' (source package linux-signed version '6.17.0-29.29') was added. linux-image-6.17.0-29-generic version '6.17.0-29.29' has the same source package name, linux-signed, as removed package linux-image-6.17.0-22-generic. As such we can use the source package version of the removed package, '6.17.0-22.22', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
},
{
"name": "linux-modules-6.17.0-29-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": "linux-modules-6.17.0-29-generic version '6.17.0-29.29' (source package linux version '6.17.0-29.29') was added. linux-modules-6.17.0-29-generic version '6.17.0-29.29' has the same source package name, linux, as removed package linux-headers-6.17.0-22. As such we can use the source package version of the removed package, '6.17.0-22.22', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
},
{
"name": "linux-tools-6.17.0-29",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": "linux-tools-6.17.0-29 version '6.17.0-29.29' (source package linux version '6.17.0-29.29') was added. linux-tools-6.17.0-29 version '6.17.0-29.29' has the same source package name, linux, as removed package linux-headers-6.17.0-22. As such we can use the source package version of the removed package, '6.17.0-22.22', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
},
{
"name": "linux-tools-6.17.0-29-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": null
},
"to_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-29.29",
"version": "6.17.0-29.29"
},
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
},
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"launchpad_bugs_fixed": [
2151099,
2150051,
2149766,
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"changes": [
{
"cves": [
{
"cve": "CVE-2026-31419",
"url": "https://ubuntu.com/security/CVE-2026-31419",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is \"last\" mid-loop. This causes the original skb to be double-consumed (double-freed). Replace the racy bond_is_last_slave() check with a simple index comparison (i + 1 == slaves_count) against the pre-snapshot slave count taken via READ_ONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the \"last\" determination stable against concurrent list mutations. The UAF can trigger the following crash: ================================================================== BUG: KASAN: slab-use-after-free in skb_clone Read of size 8 at addr ffff888100ef8d40 by task exploit/147 CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: dump_stack_lvl (lib/dump_stack.c:123) print_report (mm/kasan/report.c:379 mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:597) skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334) bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593) dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136) ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219) ip6_output (net/ipv6/ip6_output.c:250) ip6_send_skb (net/ipv6/ip6_output.c:1985) udp_v6_send_skb (net/ipv6/udp.c:1442) udpv6_sendmsg (net/ipv6/udp.c:1733) __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) __x64_sys_sendto (net/socket.c:2209) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Allocated by task 147: Freed by task 147: The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60) Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================",
"cve_priority": "medium",
"cve_public_date": "2026-04-13 14:16:00 UTC"
},
{
"cve": "CVE-2026-31431",
"url": "https://ubuntu.com/security/CVE-2026-31431",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.",
"cve_priority": "high",
"cve_public_date": "2026-04-22 09:16:00 UTC"
},
{
"cve": "CVE-2026-31533",
"url": "https://ubuntu.com/security/CVE-2026-31533",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 (\"net: tls: handle backlogging of crypto requests\"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon completion. That callback unconditionally restores the scatterlist entry (sge->offset, sge->length) and decrements ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an error, the synchronous error path in tls_do_encryption() performs the same cleanup again, double-decrementing encrypt_pending and double-restoring the scatterlist. The double-decrement corrupts the encrypt_pending sentinel (initialized to 1), making tls_encrypt_async_wait() permanently skip the wait for pending async callbacks. A subsequent sendmsg can then free the tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still pending, resulting in a use-after-free when the callback fires on the freed record. Fix this by skipping the synchronous cleanup when the -EBUSY async wait returns an error, since the callback has already handled encrypt_pending and sge restoration.",
"cve_priority": "medium",
"cve_public_date": "2026-04-23 18:16:00 UTC"
},
{
"cve": "CVE-2026-31504",
"url": "https://ubuntu.com/security/CVE-2026-31504",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.",
"cve_priority": "medium",
"cve_public_date": "2026-04-22 14:16:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-29.29 -proposed tracker (LP: #2151099)",
"",
" * CVE-2026-31419",
" - net: bonding: fix use-after-free in bond_xmit_broadcast()",
"",
" * CVE-2026-31431",
" - crypto: algif_aead - Revert to operating out-of-place",
" - crypto: algif_aead - snapshot IV for async AEAD requests",
" - crypto: authencesn - Do not place hiseq at end of dst for out-of-place",
" decryption",
" - crypto: authencesn - Fix src offset when decrypting in-place",
" - crypto: af_alg - Fix page reassignment overflow in af_alg_pull_tsgl",
" - crypto: algif_aead - Fix minimum RX size check for decryption",
"",
" * CVE-2026-31533",
" - net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption",
"",
" * CVE-2026-31504",
" - net: fix fanout UAF in packet_release() via NETDEV_UP race",
""
],
"package": "linux",
"version": "6.17.0-29.29",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2151099
],
"author": "Manuel Diewald ",
"date": "Tue, 05 May 2026 15:53:32 +0200"
},
{
"cves": [],
"log": [
"",
" * questing/linux: 6.17.0-28.28 -proposed tracker (LP: #2150051)",
"",
" * Linux kernel 6.17.0-22.22 breaks amdxdna (LP: #2149766)",
" - Revert \"iommu: disable SVA when CONFIG_X86 is set\"",
""
],
"package": "linux",
"version": "6.17.0-28.28",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2150051,
2149766
],
"author": "Mehmet Basaran ",
"date": "Thu, 23 Apr 2026 00:20:25 +0300"
},
{
"cves": [
{
"cve": "CVE-2026-23112",
"url": "https://ubuntu.com/security/CVE-2026-23112",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.",
"cve_priority": "high",
"cve_public_date": "2026-02-13 14:16:00 UTC"
},
{
"cve": "CVE-2025-71141",
"url": "https://ubuntu.com/security/CVE-2025-71141",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tilcdc: Fix removal actions in case of failed probe The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios. [ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc] Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71090",
"url": "https://ubuntu.com/security/CVE-2025-71090",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if the client already has a SHARE_ACCESS_READ open from a previous OPEN operation, this action overwrites the existing pointer without releasing its reference, orphaning the previous reference. Additionally, the function originally stored the same nfsd_file pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with only a single reference. When put_deleg_file() runs, it clears fi_rdeleg_file and calls nfs4_file_put_access() to release the file. However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when the fi_access[O_RDONLY] counter drops to zero. If another READ open exists on the file, the counter remains elevated and the nfsd_file reference from the delegation is never released. This potentially causes open conflicts on that file. Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() to encounter files with an elevated reference count that cannot be cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() because there are still nfsd_file objects allocated in that cache.",
"cve_priority": "medium",
"cve_public_date": "2026-01-13 16:16:00 UTC"
},
{
"cve": "CVE-2025-71139",
"url": "https://ubuntu.com/security/CVE-2025-71139",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: kernel/kexec: fix IMA when allocation happens in CMA area *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the \"cma=\" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e (\"kexec: enable CMA based contiguous allocation\") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71152",
"url": "https://ubuntu.com/security/CVE-2025-71152",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: properly keep track of conduit reference Problem description ------------------- DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense. There are two distinct problems. 1. The OF path, which uses of_find_net_device_by_node(), never releases the elevated refcount on the conduit's kobject. Nominally, the OF and non-OF paths should result in objects having identical reference counts taken, and it is already suspicious that dsa_dev_to_net_device() has a put_device() call which is missing in dsa_port_parse_of(), but we can actually even verify that an issue exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command \"before\" and \"after\" applying this patch: (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind we see these lines in the output diff which appear only with the patch applied: kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000) 2. After we find the conduit interface one way (OF) or another (non-OF), it can get unregistered at any time, and DSA remains with a long-lived, but in this case stale, cpu_dp->conduit pointer. Holding the net device's underlying kobject isn't actually of much help, it just prevents it from being freed (but we never need that kobject directly). What helps us to prevent the net device from being unregistered is the parallel netdev reference mechanism (dev_hold() and dev_put()). Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with the DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it. So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference. Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not make user port errors fatal\"), and the cpu_dp->conduit pointers remain valid. I haven't audited all call paths to see whether they will actually use the conduit in lack of any user port, but if they do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is associated to, and we can get into a situation where we've moved all user ports away from a conduit, thus no longer hold any reference to it via the net device tracker. But we shouldn't let it go nonetheless - see the next change in relation to dsa_tree_find_first_conduit() and LAG conduits which disappear. We have to be prepared to return to the physical conduit, so the CPU port must explicitly keep another reference to it. This is also to say: the user ports and their CPU ports may not always keep a reference to the same conduit net device, and both are needed. As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself. History and blame attribution ----------------------------- The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct. We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71142",
"url": "https://ubuntu.com/security/CVE-2025-71142",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpuset: fix warning when disabling remote partition A warning was triggered as follows: WARNING: kernel/cgroup/cpuset.c:1651 at remote_partition_disable+0xf7/0x110 RIP: 0010:remote_partition_disable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: update_prstate+0x2d3/0x580 cpuset_partition_write+0x94/0xf0 kernfs_fop_write_iter+0x147/0x200 vfs_write+0x35d/0x500 ksys_write+0x66/0xe0 do_syscall_64+0x6b/0x390 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887 Reproduction steps (on a 16-CPU machine): # cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtree_control # echo \"0-14\" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo \"0-14\" > A1/A2/cpuset.cpus.exclusive # echo \"root\" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition When CPU 15 is offlined, subpartitions_cpus gets cleared because no CPUs remain available for the top_cpuset, forcing partitions to share CPUs with the top_cpuset. In this scenario, disabling the remote partition triggers a warning stating that effective_xcpus is not a subset of subpartitions_cpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with top_cpuset). To fix this issue: 1. Only emit the warning only if subpartitions_cpus is not empty and the effective_xcpus is not a subset of subpartitions_cpus. 2. During the CPU hotplug process, invalidate partitions if subpartitions_cpus is empty.",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2025-71155",
"url": "https://ubuntu.com/security/CVE-2025-71155",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix gmap_helper_zap_one_page() again A few checks were missing in gmap_helper_zap_one_page(), which can lead to memory corruption in the guest under specific circumstances. Add the missing checks.",
"cve_priority": "medium",
"cve_public_date": "2026-01-23 15:16:00 UTC"
},
{
"cve": "CVE-2025-71134",
"url": "https://ubuntu.com/security/CVE-2025-71134",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: change all pageblocks migrate type on coalescing When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed. However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged. That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced. [ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmac_s390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNED_MODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2\tlarl\t%r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5\tbrasl\t%r14,0000034997378f60 #00000349976fa5fc: af000000\t\tmc\t0,0 >00000349976fa600: a7f4ff4c\t\tbrc\t15,00000349976fa498 00000349976fa604: b9040026\t\tlgr\t%r2,%r6 00000349976fa608: c0300088317f\tlarl\t%r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1\tbrasl\t%r14,00000349976b13d0 00000349976fa614: af000000\t\tmc\t0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---",
"cve_priority": "medium",
"cve_public_date": "2026-01-14 15:16:00 UTC"
},
{
"cve": "CVE-2026-23394",
"url": "https://ubuntu.com/security/CVE-2026-23394",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a (\"af_unix: fix garbage collect vs MSG_PEEK\"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \\ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls.",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23274",
"url": "https://ubuntu.com/security/CVE-2026-23274",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.",
"cve_priority": "medium",
"cve_public_date": "2026-03-20 09:16:00 UTC"
},
{
"cve": "CVE-2026-23209",
"url": "https://ubuntu.com/security/CVE-2026-23209",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name). In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink(): This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry. vlan is a pointer to the priv data of the link that is being created. When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create(): if (ops->newlink) err = ops->newlink(dev, ¶ms, extack); else err = register_netdevice(dev); if (err < 0) { free_netdev(dev); goto out; } and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port. Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever \"goto destroy_macvlan_port;\" path is taken. Many thanks to valis for following up on this issue.",
"cve_priority": "medium",
"cve_public_date": "2026-02-14 17:15:00 UTC"
},
{
"cve": "CVE-2026-23351",
"url": "https://ubuntu.com/security/CVE-2026-23351",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. Expired elements are still exposed to both the packet path and userspace dumpers via the live copy of the data structure. call_rcu() does not protect us: dump operations or element lookups starting after call_rcu has fired can still observe the free'd element, unless the commit phase has made enough progress to swap the clone and live pointers before any new reader has picked up the old version. This a similar approach as done recently for the rbtree backend in commit 35f83a75529a (\"netfilter: nft_set_rbtree: don't gc elements on insert\").",
"cve_priority": "medium",
"cve_public_date": "2026-03-25 11:16:00 UTC"
},
{
"cve": "CVE-2026-23231",
"url": "https://ubuntu.com/security/CVE-2026-23231",
"cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.",
"cve_priority": "high",
"cve_public_date": "2026-03-04 13:15:00 UTC"
}
],
"log": [
"",
" * questing/linux: 6.17.0-24.24 -proposed tracker (LP: #2148025)",
"",
" * Remount ext4 to readonly with data=journal mode may dump call trace",
" (LP: #2147400)",
" - ext4: fix stale xarray tags after writeback",
"",
" * System hangs during stress-ng stack test (LP: #2137755)",
" - mm, swap: fix swap cache index error when retrying reclaim",
"",
" * BUG: kernel NULL pointer dereference when starting VM inside a container",
" (LP: #2147374)",
" - apparmor: fix NULL pointer dereference in __unix_needs_revalidation",
"",
" * BUG: kernel NULL pointer dereference in amdgpu (LP: #2144577)",
" - drm/amdgpu: validate the flush_gpu_tlb_pasid()",
" - drm/amdgpu: Fix validating flush_gpu_tlb_pasid()",
"",
" * Jellyfin Desktop Flatpak doesn't work with the current AppArmor profile",
" (LP: #2142956)",
" - SAUCE: apparmor5.0.0 [53/57]: apparmor: fix af_unix local addr mediation",
" binding",
"",
" * Fine grained network mediation was broken if v8/v9 was used (LP: #2142860)",
" - SAUCE: apparmor5.0.0 [29/57]: apparmor: fix fine grained inet mediation",
" sock_file_perm",
"",
" * Enable CirrusLogic audio solution CS42L45+CS35L63 on AMD and Intel PTL",
" (LP: #2143104)",
" - ASoC: amd: acp: Add ACP7.0 match entries for cs35l56 and cs42l43",
" - ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper",
" - ASoC: amd: acp: Sort match table into most specific first",
" - ASoC: amd: acp: Rename Cirrus Logic component match entries to include",
" link and uid",
" - ASoC: amd: acp: Sort Cirrus Logic match entries",
" - ASoC: amd: acp: Add ACP7.0 match entries for Cirrus Logic parts",
" - ASoC: amd: acp: Fix Kconfig dependencies for",
" SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - [Config] Enable SND_SOC_ACPI_AMD_SDCA_QUIRKS",
" - soundwire: amd: add clock init control function",
" - soundwire: amd: refactor bandwidth calculation logic",
"",
" * CVE-2026-23112",
" - nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec",
"",
" * Canonical Kmod 2025 key rotation (LP: #2147447)",
" - [Packaging] ubuntu-compatible-signing -- make Ubuntu-Compatible-Signing",
" extensible",
" - [Packaging] ubuntu-compatible-signing -- allow consumption of positive",
" certs",
" - [Packaging] ubuntu-compatible-signing -- report the livepatch:2025 key",
" - [Config] prepare for Canonical Kmod key rotation",
" - [Packaging] ubuntu-compatible-signing -- report the kmod:2025 key",
" - [Packaging] ensure our cert rollups are always fresh",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193)",
" - mptcp: fallback earlier on simult connection",
" - mm: consider non-anon swap cache folios in folio_expected_ref_count()",
" - mptcp: ensure context reset on disconnect()",
" - wifi: mac80211: Discard Beacon frames to non-broadcast address",
" - net: phy: mediatek: fix nvmem cell reference leak in",
" mt798x_phy_calibration",
" - drm/amdgpu: Forward VMID reservation errors",
" - sched/fair: Small cleanup to sched_balance_newidle()",
" - sched/fair: Small cleanup to update_newidle_cost()",
" - sched/fair: Proportional newidle balance",
" - Revert \"iommu/amd: Skip enabling command/event buffers for kdump\"",
" - sched/proxy: Yield the donor task",
" - drm: nova: depend on CONFIG_64BIT",
" - sched/core: Add comment explaining force-idle vruntime snapshots",
" - mm/huge_memory: merge uniform_split_supported() and",
" non_uniform_split_supported()",
" - drm/amdgpu: don't attach the tlb fence for SI",
" - sched_ext: fix uninitialized ret on alloc_percpu() failure",
" - idpf: fix LAN memory regions command on some NVMs",
" - Bluetooth: MGMT: report BIS capability flags in supported settings",
" - powerpc/tools: drop `-o pipefail` in gcc check scripts",
" - net: airoha: Move net_devs registration in a dedicated routine",
" - net: wangxun: move PHYLINK dependency",
" - platform/x86/intel/pmt: Fix kobject memory leak on init failure",
" - bng_en: update module description",
" - mcb: Add missing modpost build support",
" - net: mdio: rtl9300: use scoped for loops",
" - tools/sched_ext: fix scx_show_state.py for scx_root change",
" - platform/x86/intel/pmt/discovery: use valid device pointer in",
" dev_err_probe",
" - net: fib: restore ECMP balance from loopback",
" - RDMA/mana_ib: check cqe length for kernel CQs",
" - drm/gem-shmem: Fix the MODULE_LICENSE() string",
" - kunit: Enforce task execution in {soft,hard}irq contexts",
" - ublk: don't pass q_id to ublk_queue_cmd_buf_size()",
" - ublk: implement NUMA-aware memory allocation",
" - ublk: scan partition in async way",
" - drm/xe/guc: READ/WRITE_ONCE g2h_fence->done",
" - IB/rxe: Fix missing umem_odp->umem_mutex unlock on error path",
" - hisi_acc_vfio_pci: Add .match_token_uuid callback in",
" hisi_acc_vfio_pci_migrn_ops",
" - mm, swap: do not perform synchronous discard during allocation",
" - clk: qcom: mmcc-sdm660: Add missing MDSS reset",
" - clk: qcom: Fix SM_VIDEOCC_6350 dependencies",
" - [Config] set CONFIG_SM_GCC_6350, CONFIG_SM_VIDEOCC_6350 to '-'",
" - clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615",
" - [Config] set CONFIG_QCS_{DISP,GPU,VIDEO}CC_615 to '-'",
" - arm64: dts: ti: k3-am62d2-evm: Fix regulator properties",
" - arm64: dts: ti: k3-am62d2-evm: Fix PMIC padconfig",
" - arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1",
" - arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS",
" - NFSD: Make FILE_SYNC WRITEs comply with spec",
" - nvmet: pci-epf: move DMA initialization to EPC init callback",
" - PCI: dwc: Add support for ELBI resource mapping",
" - PCI: meson: Fix parsing the DBI register region",
" - power: supply: max77705: Fix potential IRQ chip conflict when probing",
" two devices",
" - media: iris: Refine internal buffer reconfiguration logic for resolution",
" change",
" - LoongArch: Fix arch_dup_task_struct() for CONFIG_RANDSTRUCT",
" - mm/damon/tests/core-kunit: fix memory leak in",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damon_test_set_filters_default_reject()",
" - mm/damon/tests/core-kunit: handle alloc failures on",
" damos_test_filter_out()",
" - af_unix: don't post cmsg for SO_INQ unless explicitly asked for",
" - kernel/kexec: change the prototype of kimage_map_segment()",
" - selftests/mm: fix thread state check in uffd-unit-tests",
" - LoongArch: BPF: Save return address register ra to t0 before trampoline",
" - LoongArch: BPF: Enable trampoline-based tracing for module functions",
" - LoongArch: BPF: Adjust the jump offset of tail calls",
" - platform/x86: samsung-galaxybook: Fix problematic pointer cast",
" - platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops",
" - platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16",
" - platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora",
" - drm/amdgpu/sdma6: Update SDMA 6.0.3 FW version to include UMQ protected-",
" fence fix",
" - drm/rockchip: Set VOP for the DRM DMA device",
" - drm/mediatek: mtk_hdmi: Fix probe device leaks",
" - drm/mediatek: ovl_adaptor: Fix probe device leaks",
" - drm/amd: Fix unbind/rebind for VCN 4.0.5",
" - drm/rockchip: vop2: Use OVL_LAYER_SEL configuration instead of use",
" win_mask calculate used layers",
" - drm/bridge: ti-sn65dsi83: ignore PLL_UNLOCK errors",
" - drm/nouveau/gsp: Allocate fwsec-sb at boot",
" - drm/xe/eustall: Disallow 0 EU stall property values",
" - drm/xe/svm: Fix a debug printout",
" - powercap: intel_rapl: Add support for Wildcat Lake platform",
" - powercap: intel_rapl: Add support for Nova Lake processors",
" - LoongArch: BPF: Enhance the bpf_arch_text_poke() function",
" - SAUCE: remove git merge section marker",
" - Upstream stable to v6.12.65, v6.18.4",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71141",
" - drm/tilcdc: Fix removal actions in case of failed probe",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71090",
" - nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg()",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71139",
" - kernel/kexec: fix IMA when allocation happens in CMA area",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71152",
" - net: dsa: properly keep track of conduit reference",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71142",
" - cpuset: fix warning when disabling remote partition",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71155",
" - KVM: s390: Fix gmap_helper_zap_one_page() again",
"",
" * Questing update: upstream stable patchset 2026-03-24 (LP: #2146193) //",
" CVE-2025-71134",
" - mm/page_alloc: change all pageblocks migrate type on coalescing",
"",
" * CVE-2026-23394",
" - af_unix: Give up GC if MSG_PEEK intervened.",
"",
" * [SRU] MIPI camera is not working after upgrading to 6.17-oem",
" (LP: #2145171)",
" - SAUCE: ACPI: respect items already in honor_dep before skipping",
"",
" * ADATA SU680 causes repeated SATA resets and I/O errors on Ubuntu unless",
" link power management is forced to max_performance (LP: #2144060)",
" - ata: libata-core: disable LPM on ADATA SU680 SSD",
"",
" * [SRU] Fix for i915 PSR issue on SDC panels on Intel PTL (LP: #2144637)",
" - drm/i915/psr: Panel Replay SU cap dpcd read return value",
" - drm/i915/psr: Add panel granularity information into intel_connector",
" - drm/i915/psr: Use SU granularity information available in",
" intel_connector",
" - drm/dp: Add definition for Panel Replay full-line granularity",
" - drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling",
"",
" * Got black screen after clicked logout button (LP: #2143100)",
" - drm/i915/alpm: ALPM disable fixes",
"",
" * Dell Machines cannot boot into OS with 6.17.0-1012-oem (LP: #2144522)",
" - drm/amd: Disable MES LR compute W/A",
" - drm/amd: Set minimum version for set_hw_resource_1 on gfx11 to 0x52",
"",
" * [SRU] Duplicated entries in /proc//mountinfo (LP: #2143083)",
" - namespace: fix proc mount iteration",
"",
" * CVE-2026-23274",
" - netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels",
"",
" * macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path (LP: #2144380) // CVE-2026-23209",
" - macvlan: observe an RCU grace period in macvlan_common_newlink() error",
" path",
"",
" * CVE-2026-23351",
" - netfilter: nft_set_pipapo: split gc into unlink and reclaim phase",
"",
" * CVE-2026-23231",
" - netfilter: nf_tables: fix use-after-free in nf_tables_addchain()",
""
],
"package": "linux",
"version": "6.17.0-24.24",
"urgency": "medium",
"distributions": "questing",
"launchpad_bugs_fixed": [
2148025,
2147400,
2137755,
2147374,
2144577,
2142956,
2142860,
2143104,
2147447,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2146193,
2145171,
2144060,
2144637,
2143100,
2144522,
2143083,
2144380
],
"author": "Mehmet Basaran ",
"date": "Sun, 12 Apr 2026 04:26:46 +0300"
}
],
"notes": "linux-tools-6.17.0-29-generic version '6.17.0-29.29' (source package linux version '6.17.0-29.29') was added. linux-tools-6.17.0-29-generic version '6.17.0-29.29' has the same source package name, linux, as removed package linux-headers-6.17.0-22. As such we can use the source package version of the removed package, '6.17.0-22.22', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.",
"is_version_downgrade": false
}
],
"snap": []
},
"removed": {
"deb": [
{
"name": "linux-headers-6.17.0-22",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-headers-6.17.0-22-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-image-6.17.0-22-generic",
"from_version": {
"source_package_name": "linux-signed",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-modules-6.17.0-22-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-tools-6.17.0-22",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null,
"is_version_downgrade": false
},
{
"name": "linux-tools-6.17.0-22-generic",
"from_version": {
"source_package_name": "linux",
"source_package_version": "6.17.0-22.22",
"version": "6.17.0-22.22"
},
"to_version": {
"source_package_name": null,
"source_package_version": null,
"version": null
},
"cves": [],
"launchpad_bugs_fixed": [],
"changes": [],
"notes": null,
"is_version_downgrade": false
}
],
"snap": []
},
"notes": "Changelog diff for Ubuntu 25.10 questing image from release image serial 20260428 to 20260520",
"from_series": "questing",
"to_series": "questing",
"from_serial": "20260428",
"to_serial": "20260520",
"from_manifest_filename": "release_manifest.previous",
"to_manifest_filename": "manifest.current"
}