Page 10 of 10

Re: New Kernel

Posted: Mon Apr 13, 2026 4:03 am
by Grogan
Some new options:
Override RCU Tasks Trace inclusion of read-side memory barriers (TASKS_TRACE_RCU_NO_MB) [Y/n/?] (NEW) ?

CONFIG_TASKS_TRACE_RCU_NO_MB:

This option prevents the use of read-side memory barriers in
rcu_read_lock_tasks_trace() and rcu_read_unlock_tasks_trace()
even in kernels built with CONFIG_ARCH_WANTS_NO_INSTR=n, that is,
in kernels that do not have noinstr set up in entry/exit code.
By setting this option, you are promising to carefully review
use of ftrace, BPF, and friends to ensure that no tracing
operation is attached to a function that runs in that portion
of the entry/exit code that RCU does not watch, that is,
where rcu_is_watching() returns false. Alternatively, you
might choose to never remove traces except by rebooting.

Those wishing to disable read-side memory barriers for an entire
architecture can select this Kconfig option, hence the polarity.

Say Y here if you need speed and will review use of tracing.
Say N here for certain esoteric testing of RCU itself.
Take the default if you are unsure.
I said Y to that one, it sounds like good default behaviour. I don't plan on attaching any traces, anyway though.
Enable rseq-based time slice extension mechanism (RSEQ_SLICE_EXTENSION) [N/y/?] (NEW) ?

CONFIG_RSEQ_SLICE_EXTENSION:

Allows userspace to request a limited time slice extension when
returning from an interrupt to user space via the RSEQ shared
data ABI. If granted, that allows to complete a critical section,
so that other threads are not stuck on a conflicted resource,
while the task is scheduled out.

If unsure, say N.
While I do enable the rseq() syscall, I said N to that for now because I'm not sure if anything would make use of it at this time.

Also, a bunch of NFS client options for NFS 4 support. There are now separate options for NFS 4.0, 4.1 and 4.2 etc. and some additional support for things related to that. I said N to them (I actually use NFS v3 only I think, though I do have NFS 4 client support)

Ahh... scripts finished, time to edit grub and reboot!

P.S. As always with the first release, the tarball and directory it unpacks to are 7.0, but the kernel version is 7.0.0 (set in top level Makefile) which means the modules directory is going to be that etc.
[grogan@nicetry ~]$ uname -a
Linux nicetry 7.0.0 #1 SMP PREEMPT Sun Apr 12 23:58:34 EDT 2026 x86_64 GNU/Linux
My image isn't much bigger (this is with all hardware drivers built in, including amdgpu and firmware files)
[grogan@nicetry ~]$ ls -l /vmlinuz-7.0.0
-rw------- 1 root root 10462208 Apr 13 00:04 /vmlinuz-7.0.0
These are all incremental changes and it's no big deal (this kernel could have just as easily been 6.20 in sequence) but it's not every day the big number changes :-)

Re: New Kernel

Posted: Wed Apr 22, 2026 7:39 pm
by Grogan
Linux 7.0.1 now, which means distros can consider it "stable".
https://cdn.kernel.org/pub/linux/kernel ... eLog-7.0.1

This bug sounds really fucking nice:
clockevents: Add missing resets of the next_event_forced flag

commit 4096fd0e8eaea13ebe5206700b33f49635ae18e5 upstream.

The prevention mechanism against timer interrupt starvation missed to reset
the next_event_forced flag in a couple of places:

- When the clock event state changes. That can cause the flag to be
stale over a shutdown/startup sequence

- When a non-forced event is armed, which then prevents rearming before
that event. If that event is far out in the future this will cause
missed timer interrupts.

- In the suspend wakeup handler.

That led to stalls which have been reported by several people.

Add the missing resets, which fixes the problems for the reporters.

Re: New Kernel

Posted: Mon Apr 27, 2026 7:54 pm
by Grogan
Linux 7.0.2 now
https://cdn.kernel.org/pub/linux/kernel ... eLog-7.0.2

Lots of smb/ksmbd fixes and stuff, and also this:
drm/amdgpu: replace PASID IDR with XArray

commit 3c863ff920b45fa7a9b7d4cb932f466488a87a58 upstream.

Replace the PASID IDR + spinlock with XArray as noted in the TODO
left by commit ea56aa262570 ("drm/amdgpu: fix the idr allocation
flags").

The IDR conversion still has an IRQ safety issue:
amdgpu_pasid_free() can be called from hardirq context via the fence
signal path, but amdgpu_pasid_idr_lock is taken with plain spin_lock()
in process context, creating a potential deadlock:

CPU0
----
spin_lock(&amdgpu_pasid_idr_lock) // process context, IRQs on
<Interrupt>
spin_lock(&amdgpu_pasid_idr_lock) // deadlock

The hardirq call chain is:

sdma_v6_0_process_trap_irq
-> amdgpu_fence_process
-> dma_fence_signal
-> drm_sched_job_done
-> dma_fence_signal
-> amdgpu_pasid_free_cb
-> amdgpu_pasid_free

Use XArray with XA_FLAGS_LOCK_IRQ (all xa operations use IRQ-safe
locking internally) and XA_FLAGS_ALLOC1 (zero is not a valid PASID).
Both xa_alloc_cyclic() and xa_erase() then handle locking
consistently, fixing the IRQ safety issue and removing the need for
an explicit spinlock.
Stuff like this is why sane distros wait for a few point releases before shipping, unlike clever young people that don't even wait for it to be mainline, shipping release candidates. (or clever old people that don't even wait to bootstrap against the kernel API headers lol)

Re: New Kernel

Posted: Tue Apr 28, 2026 6:12 am
by Zema Bus
I'll probably never grow up lol!

Re: New Kernel

Posted: Tue Apr 28, 2026 6:52 am
by Grogan
It was mostly a dig at a recently popular distro :twisted:

Re: New Kernel

Posted: Thu Apr 30, 2026 7:05 pm
by Grogan
Linux 7.0.3 already
https://cdn.kernel.org/pub/linux/kernel ... eLog-7.0.3

Xen hypervisor security issues. I don't compile that, so it doesn't affect me.

Short changelog, here's the whole fucking thing :-)
xen/privcmd: fix double free via VMA splitting

commit 24daca4fc07f3ff8cd0e3f629cd982187f48436a upstream.

privcmd_vm_ops defines .close (privcmd_close), but neither .may_split
nor .open. When userspace does a partial munmap() on a privcmd mapping,
the kernel splits the VMA via __split_vma(). Since may_split is NULL,
the split is allowed. vm_area_dup() copies vm_private_data (a pages
array allocated in alloc_empty_pages()) into the new VMA without any
fixup, because there is no .open callback.

Both VMAs now point to the same pages array. When the unmapped portion
is closed, privcmd_close() calls:
- xen_unmap_domain_gfn_range()
- xen_free_unpopulated_pages()
- kvfree(pages)

The surviving VMA still holds the dangling pointer. When it is later
destroyed, the same sequence runs again, which leads to a double free.

Fix this issue by adding a .may_split callback denying the VMA split.

This is XSA-487 / CVE-2026-31787

Buffer overflow in drivers/xen/sys-hypervisor.c

commit 27fdbab4221b375de54bf91919798d88520c6e28 upstream.

The build id returned by HYPERVISOR_xen_version(XENVER_build_id) is
neither NUL terminated nor a string.

The first causes a buffer overflow as sprintf in buildid_show will
read and copy till it finds a NUL.

00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P|
00000010 b9 a8 01 42 6f 2e 32 |...Bo.2|
00000017

So use a memcpy instead of sprintf to have the correct value:

00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P|
00000010 b9 a8 01 42 |...B|
00000014

(the above have a hack to embed a zero inside and check it's
returned correctly).

This is XSA-485 / CVE-2026-31786

Re: New Kernel

Posted: Thu May 07, 2026 7:52 pm
by Grogan
Linux 7.0.4 today
https://cdn.kernel.org/pub/linux/kernel ... eLog-7.0.4

It's a much larger changelog today, many fixes across the board.

Re: New Kernel

Posted: Fri May 08, 2026 10:01 am
by Grogan
Linux 7.0.5 now, with the xfrm fix
https://cdn.kernel.org/pub/linux/kernel ... eLog-7.0.5
xfrm: esp: avoid in-place decrypt on shared skb frags

commit f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4 upstream.

MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP
marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),
so later paths that may modify packet data can first make a private
copy. The IPv4/IPv6 datagram append paths did not set this flag when
splicing pages into UDP skbs.

That leaves an ESP-in-UDP packet made from shared pipe pages looking
like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW
fast path for uncloned skbs without a frag_list and decrypts in place
over data that is not owned privately by the skb.

Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching
TCP. Also make ESP input fall back to skb_cow_data() when the flag is
present, so ESP does not decrypt externally backed frags in place.
Private nonlinear skb frags still use the existing fast path.

This intentionally does not change ESP output. In esp_output_head(),
the path that appends the ESP trailer to existing skb tailroom without
calling skb_cow_data() is not reachable for nonlinear skbs:
skb_tailroom() returns zero when skb->data_len is nonzero, while ESP
tailen is positive. Thus ESP output will either use the separate
destination-frag path or fall back to skb_cow_data().

Re: New Kernel

Posted: Mon May 11, 2026 7:51 pm
by Grogan
Linux 7.0.6 has the rest of that rxrpc fix
https://cdn.kernel.org/pub/linux/kernel ... eLog-7.0.6
rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present

commit aa54b1d27fe0c2b78e664a34fd0fdf7cd1960d71 upstream.

The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE
handler in rxrpc_verify_response() copy the skb to a linear one before
calling into the security ops only when skb_cloned() is true. An skb
that is not cloned but still carries externally-owned paged fragments
(e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via
__ip_append_data, or a chained skb_has_frag_list()) falls through to
the in-place decryption path, which binds the frag pages directly into
the AEAD/skcipher SGL via skb_to_sgvec().

Extend the gate to also unshare when skb_has_frag_list() or
skb_has_shared_frag() is true. This catches the splice-loopback vector
and other externally-shared frag sources while preserving the
zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC
page_pool RX, GRO). The OOM/trace handling already in place is reused.

Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()")