ALT-BU-2025-7002-7
Branch p11 update bulletin.
Package kernel-image-pine updated to version 6.12.29-alt1 for branch p11 in task 384550.
Closed vulnerabilities
BDU:2025-11792
Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11793
Уязвимость компонента ip_vs_xmit.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-11864
Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-11865
Уязвимость компонента vfs.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных
Modified: 2026-03-30
BDU:2025-11928
Уязвимость компонента bpf_jit_comp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-11929
Уязвимость компонентов arm64 ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-11970
Уязвимость функции output_userspace() компонента net/openvswitch/actions.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2025-11974
Уязвимость функции dequeue_entities() компонента kernel/sched/fair.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-11988
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12020
Уязвимость компонента arch/x86/mm/tlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12030
Уязвимость компонента oplock.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12031
Уязвимость компонента virtio-net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12032
Уязвимость компонента v3d_sched.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-18
BDU:2025-12067
Уязвимость компонента s390/pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12123
Уязвимость компонента ucsi/displayport.c ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12125
Уязвимость компонента s390/pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12126
Уязвимость функции mtk_pmic_keys_lp_reset_setup() компонента mtk-pmic-keys.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12127
Уязвимость компонента bcm2835-camera ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-16
BDU:2025-12128
Уязвимость компонента sch_htb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12242
Уязвимость компонента m_can ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12256
Уязвимость компонентов xenbus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12272
Уязвимость компонента filter.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-05
BDU:2025-12289
Уязвимость компонента fs/erofs/fileio.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-12291
Уязвимость компонента memblock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12334
Уязвимость ядра операционной системы Linux, связанная с доступом к неинициализированному указателю, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12350
Уязвимость функции st_lsm6dsx_read_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-31
BDU:2025-12351
Уязвимость функции st_lsm6dsx_read_tagged_fifo() компонента st_lsm6dsx_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-30
BDU:2025-14979
Уязвимость компонента huge_memory.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01385
Уязвимость функции smb2_get_name() модуля fs/smb/server/smb2pdu.c поддержки сервера SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01387
Уязвимость функции find_or_create_cached_dir() модуля fs/smb/client/cached_dir.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02238
Уязвимость функции __close_file_table_ids() в модуле fs/smb/server/vfs_cache.c поддержки сервера SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03117
Уязвимость функции shutdown_interception() модуля arch/x86/kvm/svm/svm.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-11-12
CVE-2025-37821
In the Linux kernel, the following vulnerability has been resolved: sched/eevdf: Fix se->slice being set to U64_MAX and resulting crash There is a code path in dequeue_entities() that can set the slice of a sched_entity to U64_MAX, which sometimes results in a crash. The offending case is when dequeue_entities() is called to dequeue a delayed group entity, and then the entity's parent's dequeue is delayed. In that case: 1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX. 2. The first for_each_sched_entity() loop dequeues the entity. 3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent. 4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_. 5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX. This throws off subsequent calculations with potentially catastrophic results. A manifestation we saw in production was: 6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number. 7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number. 8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number. 9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number. 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow. 11. Nothing appears to be eligible, so pick_eevdf() returns NULL. 12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes. Dumping the cfs_rq states from the core dumps with drgn showed tell-tale huge vruntime ranges and bogus vlag values, and I also traced se->slice being set to U64_MAX on live systems (which was usually "benign" since the rest of the runqueue needed to be in a particular state to crash). Fix it in dequeue_entities() by always setting slice from the first non-empty cfs_rq.
Modified: 2025-11-17
CVE-2025-37946
In the Linux kernel, the following vulnerability has been resolved: s390/pci: Fix duplicate pci_dev_put() in disable_slot() when PF has child VFs With commit bcb5d6c76903 ("s390/pci: introduce lock to synchronize state of zpci_dev's") the code to ignore power off of a PF that has child VFs was changed from a direct return to a goto to the unlock and pci_dev_put() section. The change however left the existing pci_dev_put() untouched resulting in a doubple put. This can subsequently cause a use after free if the struct pci_dev is released in an unexpected state. Fix this by removing the extra pci_dev_put().
Modified: 2026-03-17
CVE-2025-37947
In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds stream writes by validating *pos ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.
- https://git.kernel.org/stable/c/04c8a38c60346bb5a7c49b276de7233f703ce9cb
- https://git.kernel.org/stable/c/0ca6df4f40cf4c32487944aaf48319cb6c25accc
- https://git.kernel.org/stable/c/7f61da79df86fd140c7768e668ad846bfa7ec8e1
- https://git.kernel.org/stable/c/d62ba16563a86aae052f96d270b3b6f78fca154c
- https://git.kernel.org/stable/c/e6356499fd216ed6343ae0363f4c9303f02c5034
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://github.com/doyensec/KSMBD-CVE-2025-37947/blob/main/CVE-2025-37947.c
Modified: 2025-12-18
CVE-2025-37948
In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next. On exit from a BPF program, emit the BHB mititgation sequence. This is only applied for 'classic' cBPF programs that are loaded by seccomp.
- https://git.kernel.org/stable/c/0dfefc2ea2f29ced2416017d7e5b1253a54c2735
- https://git.kernel.org/stable/c/38c345fd54afd9d6ed8d3fcddf3f6ea23887bf78
- https://git.kernel.org/stable/c/42a20cf51011788f04cf2adbcd7681f02bdb6c27
- https://git.kernel.org/stable/c/852b8ae934b5cbdc62496fa56ce9969aa2edda7f
- https://git.kernel.org/stable/c/8fe5c37b0e08a97cf0210bb75970e945aaaeebab
- https://git.kernel.org/stable/c/993f63239c219696aef8887a4e7d3a16bf5a8ece
- https://git.kernel.org/stable/c/c6a8735d841bcb7649734bb3a787bb174c67c0d8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-37949
In the Linux kernel, the following vulnerability has been resolved:
xenbus: Use kref to track req lifetime
Marek reported seeing a NULL pointer fault in the xenbus_thread
callstack:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: e030:__wake_up_common+0x4c/0x180
Call Trace:
- https://git.kernel.org/stable/c/0e94a246bb6d9538010b6c02d2b1d4717a97b2e5
- https://git.kernel.org/stable/c/1f0304dfd9d217c2f8b04a9ef4b3258a66eedd27
- https://git.kernel.org/stable/c/2466b0f66795c3c426cacc8998499f38031dbb59
- https://git.kernel.org/stable/c/4d260a5558df4650eb87bc41b2c9ac2d6b2ba447
- https://git.kernel.org/stable/c/8b02f85e84dc6f7c150cef40ddb69af5a25659e5
- https://git.kernel.org/stable/c/8e9c8a0393b5f85f1820c565ab8105660f4e8f92
- https://git.kernel.org/stable/c/cbfaf46b88a4c01b64c4186cdccd766c19ae644c
- https://git.kernel.org/stable/c/f1bcac367bc95631afbb918348f30dec887d0e1b
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-17
CVE-2025-37951
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Add job to pending list if the reset was skipped When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1] and [2]. Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout.
- https://git.kernel.org/stable/c/12125f7d9c15e6d8ac91d10373b2db2f17dcf767
- https://git.kernel.org/stable/c/35e4079bf1a2570abffce6ababa631afcf8ea0e5
- https://git.kernel.org/stable/c/422a8b10ba42097a704d6909ada2956f880246f2
- https://git.kernel.org/stable/c/5235b56b7e5449d990d21d78723b1a5e7bb5738e
- https://git.kernel.org/stable/c/a5f162727b91e480656da1876247a91f651f76de
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-17
CVE-2025-37952
In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix UAF in __close_file_table_ids A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this. The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from the IDR and which already use this same lock.
Modified: 2025-12-17
CVE-2025-37953
In the Linux kernel, the following vulnerability has been resolved: sch_htb: make htb_deactivate() idempotent Alan reported a NULL pointer dereference in htb_next_rb_node() after we made htb_qlen_notify() idempotent. It turns out in the following case it introduced some regression: htb_dequeue_tree(): |-> fq_codel_dequeue() |-> qdisc_tree_reduce_backlog() |-> htb_qlen_notify() |-> htb_deactivate() |-> htb_next_rb_node() |-> htb_deactivate() For htb_next_rb_node(), after calling the 1st htb_deactivate(), the clprio[prio]->ptr could be already set to NULL, which means htb_next_rb_node() is vulnerable here. For htb_deactivate(), although we checked qlen before calling it, in case of qlen==0 after qdisc_tree_reduce_backlog(), we may call it again which triggers the warning inside. To fix the issues here, we need to: 1) Make htb_deactivate() idempotent, that is, simply return if we already call it before. 2) Make htb_next_rb_node() safe against ptr==NULL. Many thanks to Alan for testing and for the reproducer.
- https://git.kernel.org/stable/c/31ff70ad39485698cf779f2078132d80b57f6c07
- https://git.kernel.org/stable/c/3769478610135e82b262640252d90f6efb05be71
- https://git.kernel.org/stable/c/98cd7ed92753090a714f0802d4434314526fe61d
- https://git.kernel.org/stable/c/99ff8a20fd61315bf9ae627440a5ff07d22ee153
- https://git.kernel.org/stable/c/a9945f7cf1709adc5d2d31cb6cfc85627ce299a8
- https://git.kernel.org/stable/c/c2d25fddd867ce20a266806634eeeb5c30cb520c
- https://git.kernel.org/stable/c/c4792b9e38d2f61b07eac72f10909fa76130314b
- https://git.kernel.org/stable/c/c928dd4f6bf0c25c72b11824a1e9ac9bd37296a0
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37954
In the Linux kernel, the following vulnerability has been resolved: smb: client: Avoid race in open_cached_dir with lease breaks A pre-existing valid cfid returned from find_or_create_cached_dir might race with a lease break, meaning open_cached_dir doesn't consider it valid, and thinks it's newly-constructed. This leaks a dentry reference if the allocation occurs before the queued lease break work runs. Avoid the race by extending holding the cfid_list_lock across find_or_create_cached_dir and when the result is checked.
Modified: 2025-11-14
CVE-2025-37955
In the Linux kernel, the following vulnerability has been resolved: virtio-net: free xsk_buffs on error in virtnet_xsk_pool_enable() The selftests added to our CI by Bui Quang Minh recently reveals that there is a mem leak on the error path of virtnet_xsk_pool_enable(): unreferenced object 0xffff88800a68a000 (size 2048): comm "xdp_helper", pid 318, jiffies 4294692778 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): __kvmalloc_node_noprof+0x402/0x570 virtnet_xsk_pool_enable+0x293/0x6a0 (drivers/net/virtio_net.c:5882) xp_assign_dev+0x369/0x670 (net/xdp/xsk_buff_pool.c:226) xsk_bind+0x6a5/0x1ae0 __sys_bind+0x15e/0x230 __x64_sys_bind+0x72/0xb0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Modified: 2025-11-14
CVE-2025-37956
In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent rename with empty string Client can send empty newname string to ksmbd server. It will cause a kernel oops from d_alloc. This patch return the error when attempting to rename a file or directory with an empty new name string.
Modified: 2025-11-14
CVE-2025-37957
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception
Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode
on vCPU reset") addressed an issue where a triple fault occurring in
nested mode could lead to use-after-free scenarios. However, the commit
did not handle the analogous situation for System Management Mode (SMM).
This omission results in triggering a WARN when KVM forces a vCPU INIT
after SHUTDOWN interception while the vCPU is in SMM. This situation was
reprodused using Syzkaller by:
1) Creating a KVM VM and vCPU
2) Sending a KVM_SMI ioctl to explicitly enter SMM
3) Executing invalid instructions causing consecutive exceptions and
eventually a triple fault
The issue manifests as follows:
WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112
kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112
Modules linked in:
CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted
6.1.130-syzkaller-00157-g164fe5dde9b6 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.12.0-1 04/01/2014
RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112
Call Trace:
Modified: 2025-12-16
CVE-2025-37958
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: fix dereferencing invalid pmd migration entry
When migrating a THP, concurrent access to the PMD migration entry during
a deferred split scan can lead to an invalid address access, as
illustrated below. To prevent this invalid access, it is necessary to
check the PMD migration entry and return early. In this context, there is
no need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the
equality of the target folio. Since the PMD migration entry is locked, it
cannot be served as the target.
Mailing list discussion and explanation from Hugh Dickins: "An anon_vma
lookup points to a location which may contain the folio of interest, but
might instead contain another folio: and weeding out those other folios is
precisely what the "folio != pmd_folio((*pmd)" check (and the "risk of
replacing the wrong folio" comment a few lines above it) is for."
BUG: unable to handle page fault for address: ffffea60001db008
CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60
Call Trace:
- https://git.kernel.org/stable/c/22f6368768340260e862f35151d2e1c55cb1dc75
- https://git.kernel.org/stable/c/3977946f61cdba87b6b5aaf7d7094e96089583a5
- https://git.kernel.org/stable/c/6166c3cf405441f7147b322980144feb3cefc617
- https://git.kernel.org/stable/c/753f142f7ff7d2223a47105b61e1efd91587d711
- https://git.kernel.org/stable/c/9468afbda3fbfcec21ac8132364dff3dab945faf
- https://git.kernel.org/stable/c/be6e843fc51a584672dfd9c4a6a24c8cb81d5fb7
- https://git.kernel.org/stable/c/ef5706bed97e240b4abf4233ceb03da7336bc775
- https://git.kernel.org/stable/c/fbab262b0c8226c697af1851a424896ed47dedcc
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html
Modified: 2025-12-16
CVE-2025-37959
In the Linux kernel, the following vulnerability has been resolved: bpf: Scrub packet on bpf_redirect_peer When bpf_redirect_peer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace. As one example, this is causing Cilium to drop traffic when using bpf_redirect_peer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2, In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, __xfrm_policy_check drops the packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption. This patch fixes this by scrubbing the packet when using bpf_redirect_peer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.
- https://git.kernel.org/stable/c/355b0526336c0bf2bf7feaca033568ede524f763
- https://git.kernel.org/stable/c/9e15ef33ba39fb6d9d1f51445957f16983a9437a
- https://git.kernel.org/stable/c/b37e54259cab4f78b53953d6f6268b85f07bef3e
- https://git.kernel.org/stable/c/c4327229948879814229b46aa26a750718888503
- https://git.kernel.org/stable/c/de1067cc8cf0e8c11ae20cbe5c467aef19d04ded
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37960
In the Linux kernel, the following vulnerability has been resolved: memblock: Accept allocated memory before use in memblock_double_array() When increasing the array size in memblock_double_array() and the slab is not yet available, a call to memblock_find_in_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest: RIP: 0010:memcpy_orig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblock_double_array+0xff/0x310 memblock_add_range+0x1fb/0x2f0 memblock_reserve+0x4f/0xa0 memblock_alloc_range_nid+0xac/0x130 memblock_alloc_internal+0x53/0xc0 memblock_alloc_try_nid+0x3d/0xa0 swiotlb_init_remap+0x149/0x2f0 mem_init+0xb/0xb0 mm_core_init+0x8f/0x350 start_kernel+0x17e/0x5d0 x86_64_start_reservations+0x14/0x30 x86_64_start_kernel+0x92/0xa0 secondary_startup_64_no_verify+0x194/0x19b Mitigate this by calling accept_memory() on the memory range returned before the slab is available. Prior to v6.12, the accept_memory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the accept_memory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.
Modified: 2025-12-16
CVE-2025-37961
In the Linux kernel, the following vulnerability has been resolved: ipvs: fix uninit-value for saddr in do_output_route4 syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---
- https://git.kernel.org/stable/c/0160ac84fb03a0bd8dce8a42cb25bfaeedd110f4
- https://git.kernel.org/stable/c/7d0032112a0380d0b8d7c9005f621928a9b9fc76
- https://git.kernel.org/stable/c/a3a1b784791a3cbfc6e05c4d8a3c321ac5136e25
- https://git.kernel.org/stable/c/adbc8cc1162951cb152ed7f147d5fbd35ce3e62f
- https://git.kernel.org/stable/c/e34090d7214e0516eb8722aee295cb2507317c07
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37962
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix memory leak in parse_lease_state() The previous patch that added bounds check for create lease context introduced a memory leak. When the bounds check fails, the function returns NULL without freeing the previously allocated lease_ctx_info structure. This patch fixes the issue by adding kfree(lreq) before returning NULL in both boundary check cases.
- https://git.kernel.org/stable/c/2148d34371b06dac696c0497a98a6bf905a51650
- https://git.kernel.org/stable/c/829e19ef741d9e9932abdc3bee5466195e0852cf
- https://git.kernel.org/stable/c/af9e2d4732a548db8f6f5a90c2c20a789a3d7240
- https://git.kernel.org/stable/c/eb4447bcce915b43b691123118893fca4f372a8f
- https://git.kernel.org/stable/c/facf22c1a394c1e023dab5daf9a494f722771e1c
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-12-16
CVE-2025-37963
In the Linux kernel, the following vulnerability has been resolved: arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB. In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.
- https://git.kernel.org/stable/c/038866e01ea5e5a3d948898ac216e531e7848669
- https://git.kernel.org/stable/c/477481c4348268136227348984b6699d6370b685
- https://git.kernel.org/stable/c/6e52d043f7dbf1839a24a3fab2b12b0d3839de7a
- https://git.kernel.org/stable/c/80251f62028f1ab2e09be5ca3123f84e8b00389a
- https://git.kernel.org/stable/c/df53d418709205450a02bb4d71cbfb4ff86f2c1e
- https://git.kernel.org/stable/c/e5f5100f1c64ac6c72671b2cf6b46542fce93706
- https://git.kernel.org/stable/c/f300769ead032513a68e4a02e806393402e626f8
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37964
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: // Turn on IPIs for this CPU/mm combination, but only // if should_flush_tlb() agrees: cpumask_set_cpu(cpu, mm_cpumask(next)); next_tlb_gen = atomic64_read(&next->context.tlb_gen); choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); load_new_mm_cr3(need_flush); // ^ After 'need_flush' is set to false, IPIs *MUST* // be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); // ^ Not until this point does should_flush_tlb() // become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy "just about to write CR3" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.
- https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477
- https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac
- https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59
- https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89
- https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f
- https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37965
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix invalid context error in dml helper [Why] "BUG: sleeping function called from invalid context" error. after: "drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()" The populate_dml_plane_cfg_from_plane_state() uses the GFP_KERNEL flag for memory allocation, which shouldn't be used in atomic contexts. The allocation is needed only for using another helper function get_scaler_data_for_plane(). [How] Modify helpers to pass a pointer to scaler_data within existing context, eliminating the need for dynamic memory allocation/deallocation and copying. (cherry picked from commit bd3e84bc98f81b44f2c43936bdadc3241d654259)
Modified: 2025-12-16
CVE-2025-37969
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/16857370b3a30663515956b3bd27f3def6a2cf06
- https://git.kernel.org/stable/c/35b8c0a284983b71d92d082c54b7eb655ed4194f
- https://git.kernel.org/stable/c/4db7d923a8c298788181b796f71adf6ca499f966
- https://git.kernel.org/stable/c/76727a1d81afde77d21ea8feaeb12d34605be6f4
- https://git.kernel.org/stable/c/8114ef86e2058e2554111b793596f17bee23fa15
- https://git.kernel.org/stable/c/9ce662851380fe2018e36e15c0bdcb1ad177ed95
- https://git.kernel.org/stable/c/9ddb4cf2192c213e4dba1733bbcdc94cf6d85bf7
- https://git.kernel.org/stable/c/dadf9116108315f2eb14c7415c7805f392c476b4
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37970
In the Linux kernel, the following vulnerability has been resolved: iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifo Prevent st_lsm6dsx_read_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.
- https://git.kernel.org/stable/c/159ca7f18129834b6f4c7eae67de48e96c752fc9
- https://git.kernel.org/stable/c/3bb6c02d6fe8347ce1785016d135ff539c20043c
- https://git.kernel.org/stable/c/6c4a5000618a8c44200d455c92e2f2a4db264717
- https://git.kernel.org/stable/c/84e39f628a3a3333add99076e4d6c8b42b12d3a0
- https://git.kernel.org/stable/c/a1cad8a3bca41dead9980615d35efc7bff1fd534
- https://git.kernel.org/stable/c/da33c4167b9cc1266a97215114cb74679f881d0c
- https://git.kernel.org/stable/c/f06a1a1954527cc4ed086d926c81ff236b2adde9
- https://git.kernel.org/stable/c/f3cf233c946531a92fe651ff2bd15ebbe60630a7
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-14
CVE-2025-37971
In the Linux kernel, the following vulnerability has been resolved: staging: bcm2835-camera: Initialise dev in v4l2_dev Commit 42a2f6664e18 ("staging: vc04_services: Move global g_state to vchiq_state") changed mmal_init to pass dev->v4l2_dev.dev to vchiq_mmal_init, however nothing iniitialised dev->v4l2_dev, so we got a NULL pointer dereference. Set dev->v4l2_dev.dev during bcm2835_mmal_probe. The device pointer could be passed into v4l2_device_register to set it, however that also has other effects that would need additional changes.
Modified: 2025-12-16
CVE-2025-37972
In the Linux kernel, the following vulnerability has been resolved: Input: mtk-pmic-keys - fix possible null pointer dereference In mtk_pmic_keys_probe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer. Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.
- https://git.kernel.org/stable/c/09429ddb5a91e9e8f72cd18c012ec4171c2f85ec
- https://git.kernel.org/stable/c/11cdb506d0fbf5ac05bf55f5afcb3a215c316490
- https://git.kernel.org/stable/c/334d74a798463ceec02a41eb0e2354aaac0d6249
- https://git.kernel.org/stable/c/619c05fb176c272ac6cecf723446b39723ee6d97
- https://git.kernel.org/stable/c/90fa6015ff83ef1c373cc61b7c924ab2bcbe1801
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
Modified: 2025-11-14
CVE-2025-37973
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation Currently during the multi-link element defragmentation process, the multi-link element length added to the total IEs length when calculating the length of remaining IEs after the multi-link element in cfg80211_defrag_mle(). This could lead to out-of-bounds access if the multi-link element or its corresponding fragment elements are the last elements in the IEs buffer. To address this issue, correctly calculate the remaining IEs length by deducting the multi-link element end offset from total IEs end offset.
Modified: 2025-11-14
CVE-2025-37974
In the Linux kernel, the following vulnerability has been resolved: s390/pci: Fix missing check for zpci_create_device() error return The zpci_create_device() function returns an error pointer that needs to be checked before dereferencing it as a struct zpci_dev pointer. Add the missing check in __clp_add() where it was missed when adding the scan_list in the fixed commit. Simply not adding the device to the scan list results in the previous behavior.
Modified: 2025-11-14
CVE-2025-37993
In the Linux kernel, the following vulnerability has been resolved:
can: m_can: m_can_class_allocate_dev(): initialize spin lock on device probe
The spin lock tx_handling_spinlock in struct m_can_classdev is not
being initialized. This leads the following spinlock bad magic
complaint from the kernel, eg. when trying to send CAN frames with
cansend from can-utils:
| BUG: spinlock bad magic on CPU#0, cansend/95
| lock: 0xff60000002ec1010, .magic: 00000000, .owner:
Modified: 2025-12-16
CVE-2025-37994
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: displayport: Fix NULL pointer access This patch ensures that the UCSI driver waits for all pending tasks in the ucsi_displayport_work workqueue to finish executing before proceeding with the partner removal.
- https://git.kernel.org/stable/c/076ab0631ed4928905736f1701e25f1e722bc086
- https://git.kernel.org/stable/c/14f298c52188c34acde9760bf5abc669c5c36fdb
- https://git.kernel.org/stable/c/312d79669e71283d05c05cc49a1a31e59e3d9e0e
- https://git.kernel.org/stable/c/5ad298d6d4aebe1229adba6427e417e89a5208d8
- https://git.kernel.org/stable/c/7804c4d63edfdd5105926cc291e806e8f4ce01b5
- https://git.kernel.org/stable/c/9dda1e2a666a8a32ce0f153b5dee05c7351f1020
- https://git.kernel.org/stable/c/a9931f1b52b2d0bf3952e003fd5901ea7eb851ed
- https://git.kernel.org/stable/c/e9b63faf5c97deb43fc39a52edbc39d626cc14bf
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37995
In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.
- https://git.kernel.org/stable/c/31d8df3f303c3ae9115230820977ef8c35c88808
- https://git.kernel.org/stable/c/93799fb988757cdacf19acba57807746c00378e6
- https://git.kernel.org/stable/c/9e7b49ce4f9d0cb5b6e87db9e07a2fb9e754b0dd
- https://git.kernel.org/stable/c/a63d99873547d8b39eb2f6db79dd235761e7098a
- https://git.kernel.org/stable/c/a6aeb739974ec73e5217c75a7c008a688d3d5cf1
- https://git.kernel.org/stable/c/d63851049f412cdfadaeef7a7eaef5031d11c1e9
- https://git.kernel.org/stable/c/f1c71b4bd721a4ea21da408806964b10468623f2
- https://git.kernel.org/stable/c/faa9059631d3491d699c69ecf512de9e1a3d6649
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37997
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix region locking in hash types Region locking introduced in v5.6-rc4 contained three macros to handle the region locks: ahash_bucket_start(), ahash_bucket_end() which gave back the start and end hash bucket values belonging to a given region lock and ahash_region() which should give back the region lock belonging to a given hash bucket. The latter was incorrect which can lead to a race condition between the garbage collector and adding new elements when a hash type of set is defined with timeouts.
- https://git.kernel.org/stable/c/00cfc5fad1491796942a948808afb968a0a3f35b
- https://git.kernel.org/stable/c/226ce0ec38316d9e3739e73a64b6b8304646c658
- https://git.kernel.org/stable/c/6e002ecc1c8cfdfc866b9104ab7888da54613e59
- https://git.kernel.org/stable/c/82c1eb32693bc48251d92532975e19160987e5b9
- https://git.kernel.org/stable/c/8478a729c0462273188263136880480729e9efca
- https://git.kernel.org/stable/c/a3dfec485401943e315c394c29afe2db8f9481d6
- https://git.kernel.org/stable/c/aa77294b0f73bb8265987591460cd25b8722c3df
- https://git.kernel.org/stable/c/e2ab67672b2288521a6146034a971f9a82ffc5c5
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-12-16
CVE-2025-37998
In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed.
- https://git.kernel.org/stable/c/0236742bd959332181c1fcc41a05b7b709180501
- https://git.kernel.org/stable/c/06b4f110c79716c181a8c5da007c259807840232
- https://git.kernel.org/stable/c/47f7f00cf2fa3137d5c0416ef1a71bdf77901395
- https://git.kernel.org/stable/c/4fa672cbce9c86c3efb8621df1ae580d47813430
- https://git.kernel.org/stable/c/6712dc21506738f5f22b4f68b7c0d9e0df819dbd
- https://git.kernel.org/stable/c/6beb6835c1fbb3f676aebb51a5fee6b77fed9308
- https://git.kernel.org/stable/c/bca8df998cce1fead8cbc69144862eadc2e34c87
- https://git.kernel.org/stable/c/ec334aaab74705cc515205e1da3cb369fdfd93cd
- https://www.zerodayinitiative.com/advisories/ZDI-25-307/
- https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html
Modified: 2025-11-14
CVE-2025-37999
In the Linux kernel, the following vulnerability has been resolved: fs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio() If bio_add_folio() fails (because it is full), erofs_fileio_scan_folio() needs to submit the I/O request via erofs_fileio_rq_submit() and allocate a new I/O request with an empty `struct bio`. Then it retries the bio_add_folio() call. However, at this point, erofs_onlinefolio_split() has already been called which increments `folio->private`; the retry will call erofs_onlinefolio_split() again, but there will never be a matching erofs_onlinefolio_end() call. This leaves the folio locked forever and all waiters will be stuck in folio_wait_bit_common(). This bug has been added by commit ce63cb62d794 ("erofs: support unencoded inodes for fileio"), but was practically unreachable because there was room for 256 folios in the `struct bio` - until commit 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") which reduced the array capacity to 16 folios. It was now trivial to trigger the bug by manually invoking readahead from userspace, e.g.: posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED); This should be fixed by invoking erofs_onlinefolio_split() only after bio_add_folio() has succeeded. This is safe: asynchronous completions invoking erofs_onlinefolio_end() will not unlock the folio because erofs_fileio_scan_folio() is still holding a reference to be released by erofs_onlinefolio_end() at the end.
Closed vulnerabilities
BDU:2026-03380
Уязвимость облачного программного обеспечения для создания и использования хранилища данных Nextcloud Server и Nextcloud Enterprise Server, связанная с ошибками в настройках безопасности, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2025-09-30
CVE-2025-47790
Nextcloud Server is a self hosted personal cloud system. Nextcloud Server prior to 29.0.15, 30.0.9, and 31.0.3 and Nextcloud Enterprise Server prior to 26.0.13.15, 27.1.11.15, 28.0.14.6, 29.0.15, 30.0.9, and 31.0.3 have a bug with session handling. The bug caused skipping the second factor confirmation after a successful login with the username and password when the server was configured with `remember_login_cookie_lifetime` set to `0`, once the session expired on the page to select the second factor and the page is reloaded. Nextcloud Server 29.0.15, 30.0.9, and 31.0.3 and Nextcloud Enterprise Server is upgraded to 26.0.13.15, 27.1.11.15, 28.0.14.6, 29.0.15, 30.0.9 and 31.0.3 contain a patch. As a workaround, set the `remember_login_cookie_lifetime` in config.php to a value other than `0`, e.g. `900`. Beware that this is only a workaround for new sessions created after the configuration change. System administration can delete affected sessions.
Modified: 2025-09-30
CVE-2025-47794
Nextcloud Server is a self hosted personal cloud system. In Nextcloud Server prior to 29.0.13, 30.0.7, and 31.0.1 and Nextcloud Enterprise Server prior to 26.0.13.13, 27.1.11.13, 28.0.14.4, 29.0.13, 30.0.7, and 31.0.1, an attacker on a multi-user system may read temporary files from Nextcloud running with a different user account, or run a symlink attack. Nextcloud Server versions 29.0.13, 30.0.7, and 31.0.1 and Nextcloud Enterprise Server 26.0.13.13, 27.1.11.13, 28.0.14.4, 29.0.13, 30.0.7, and 31.0.1 fix the issue. No known workarounds are available.
Modified: 2025-12-10
CVE-2025-66552
Nextcloud Server is a self hosted personal cloud system. In Nextcloud Server and Enterprise Server prior to 30.0.9 and 31.0.1, incorrect path handling with groupfolders caused the admin_audit app to not properly log all actions on files and folders inside groupfolders. This vulnerability is fixed in Nextcloud Server and Enterprise Server prior to 30.0.9 and 31.0.1.
Package alterator-browser-qt6 updated to version 3.6.5-alt2 for branch p11 in task 383260.
Closed bugs
У alterator-browser-qt6 не отображается значок приложения в wayland
Package postgresql17-1C updated to version 17.2-alt9 for branch p11 in task 383528.
Closed vulnerabilities
Modified: 2026-04-20
BDU:2025-05405
Уязвимость библиотеки libpq системы управления базами данных PostgreSQL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-15
CVE-2025-4207
Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination. This affects the database server and also libpq. Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.
Package postgresql16 updated to version 16.9-alt1 for branch p11 in task 383528.
Closed vulnerabilities
Modified: 2026-04-20
BDU:2025-05405
Уязвимость библиотеки libpq системы управления базами данных PostgreSQL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-15
CVE-2025-4207
Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination. This affects the database server and also libpq. Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.
Package postgresql14 updated to version 14.18-alt1 for branch p11 in task 383528.
Closed vulnerabilities
Modified: 2026-04-20
BDU:2025-05405
Уязвимость библиотеки libpq системы управления базами данных PostgreSQL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-15
CVE-2025-4207
Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination. This affects the database server and also libpq. Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.
Package postgresql17 updated to version 17.5-alt1 for branch p11 in task 383528.
Closed vulnerabilities
Modified: 2026-04-20
BDU:2025-05405
Уязвимость библиотеки libpq системы управления базами данных PostgreSQL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-15
CVE-2025-4207
Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination. This affects the database server and also libpq. Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.
Package postgresql13 updated to version 13.21-alt1 for branch p11 in task 383528.
Closed vulnerabilities
Modified: 2026-04-20
BDU:2025-05405
Уязвимость библиотеки libpq системы управления базами данных PostgreSQL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-15
CVE-2025-4207
Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination. This affects the database server and also libpq. Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.
Package postgresql15 updated to version 15.13-alt1 for branch p11 in task 383528.
Closed vulnerabilities
Modified: 2026-04-20
BDU:2025-05405
Уязвимость библиотеки libpq системы управления базами данных PostgreSQL, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-04-15
CVE-2025-4207
Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination. This affects the database server and also libpq. Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.
