-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On Mon, 2024-07-08 at 12:37 -0400, Will Dormann wrote: As reported in the Debian bug, running the program repeatedly with a 2MB file will report the same address every time on a vulnerable system, and will be randomized on a system that is behaving as expected.

In testing some platforms that I had readily available, I've concluded:   - Modern (e.g. 6.x kernel) x86 platforms load a large-enough libc at the same address every time. (i.e. no practical ASLR -- "ASLRn't")   -  Modern (e.g. 6.x kernel and large-enough libc) x8664 platforms running 32-bit code will load a large-enough library at the same address every time.   - Modern x8664 systems with the CVE-2024-26621 patch will randomize the load address of large libraries loaded by 32-bit apps.   - Modern x86 systems with the CVE-2024-26621 patch will NOT ranzomize the load address of large libraries.  (i.e. is still vulnerable to "ASLRn't" despite the patch) Hey,

I'm testing on my Debian sid laptop with Linux kernel 6.9.7-1. This is amd64 but running test-mmap built with -m32, and I get:

for i in {0..10}; do ./test-mmap < zeros; done mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7df3000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d98000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d6f000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7de7000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7df6000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7cfd000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d25000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d48000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7dad000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7d7b000 mmap(NULL, 2097152, PROTREAD, MAPPRIVATE|MAPDENYWRITE, 0, 0) = 0xf7df4000

So it looks to me like it's “properly” randomized (for a 32b process). I don't have a 32b install handy so I can't test but I'd assume the -m32 to exhibit the same behavior? This is with vm.mmaprndcompatbits=8.

Or am I doing something wrong? - -- Yves-Alexis -----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmaO9PsACgkQ3rYcyPpX RFtwbAf/esGTSILYL1Seffq43QtauizeyRAth/3U2o39SbC/KD5Bpx2wwT3+3WX5 ag96yhhBWpf6ef3JgSlblYqCZeFLRFyVYbpLQm4GpfVHDOzvJI1qaF6wPlxyXetn CFy/mQq/CWVNNQ9BH4FvU0SRwaKa7ijszvkDk/RsqS/8e5nR5ufGDyH0LlZU8HJ4 LTLQLLHUA1Xt9xXhBuuNm7iMh0HmesQKOQcPQM0/e6ea7I3enLJNm14gv3eYWUIO RnG+TqwpbGW1E4NlcxZ7qo7sXabmn6tKTg5gQh5X9ADDgW0rvpeKEtYda1rO8M79 /od7a49ITS3XR7tjNswxNBdqelt8Tg== =8zdL -----END PGP SIGNATURE-----

Hi Bernd,

On Tue, Jul 14, 2026 at 01:19:18AM +0200, Bernd Zeimetz wrote: few hours ago we had a webhost running Debian kernel 6.12.90+deb13.1-amd64 being compromised using a root exploit. This is quite realistic. You'd need 6.12.95 to have the below fixes (quoting from Debian package changelog) for vulnerabilities with public exploits:

- eventpoll: fix epremove struct eventpoll / struct file UAF (CVE-2026-46242)

https://www.openwall.com/lists/oss-security/2026/07/08/13

- ipv6: account for fraggap on the paged allocation path (CVE-2026-53362)

https://github.com/sgkdev/ipv6fragescape

(I expect a proper oss-security posting on the latter issue soon.) Unfortunately not with many useful traces left, the only obvious happening was loading the afalg module (not used by other modules). Probably the attacker ran many exploits, including for already fixed issues such as Copy Fail, which may have left these traces otherwise unrelated to whatever attack ultimately succeeded. I know that afalg is marked as deprecated for 7.2, but is there any known exploit or issue that affects kernels of current distribution? Known exploits against the kernel you were running, yes, but it wasn't current for your distro.

Alexander

P.S. This isn't a Linux-only list, so when starting new threads let's not imply and omit Linux from the Subject line when talking about Linux kernel issues.

Hi,

https://lists.debian.org/debian-security-announce/2026/msg00441.html notes that:

"Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks."

Where "several" is a list of 1,313 CVE IDs.

I understand that this is a result of the Linux kernel team assigning a CVE ID for virtually any change combined with the onslaught of AI assisted findings, but I think a security advisory of this sort serves no meaningful purpose and illustrates the argument that it's pointless for defenders to attempt to track and assess individual vulnerabilities.

At the same time, automatically and frequently pulling and applying all updates without scrutiny isn't really an option for large scale, multi-purpose environments either -- many of the vulnerabilities will not apply to them at all, and the churn may introduce other problems.

The only reasonable approach I see is to hunker down, do all the basics that should have been done before (disable unused modules, don't use containers as a reliable security boundary, reduce attack surface, ...), but at this point I've come to believe that multi-user linux systems may effectively no longer be viable, as a LPE ought to be assumed.

I don't know how everybody else approaches this shift.

-Jan

On Tue, Sep 29, 2026 at 09:16:35AM -0400, Jan Schaumann wrote: Where "several" is a list of 1,313 CVE IDs.

I understand that this is a result of the Linux kernel team assigning a CVE ID for virtually any change combined with the onslaught of AI assisted findings, but I think a security advisory of this sort serves no meaningful purpose and illustrates the argument that it's pointless for defenders to attempt to track and assess individual vulnerabilities. Hello, I think the number also reflects Debian maintainers' effor to avoid too much churn... You check Debian changelog to select issues most relevant to your environment reasonably quickly (in couple hours :-( ) (disable unused modules, don't use containers as a reliable security boundary, reduce attack surface, ...), but at this point I've come to believe that multi-user linux systems may effectively no longer be viable, as a LPE ought to be assumed. Nothing is 100% secure, I hope we will run out of the most serious vulnerabilities soon at this pace...

Regards, Zdenek Salvet salvet () ics muni cz Institute of Computer Science of Masaryk University, Brno, Czech Republic and CESNET, z.s.p.o., Prague, Czech Republic Phone: ++420-549 49 6534 Fax: ++420-541 212 747 ---------------------------------------------------------------------------- Teamwork is essential -- it allows you to blame someone else.