Re: systemd/247.3-7+deb11u8
On 11/04/2026 20:32, Sylvain Beucler wrote:
On 08/04/2026 05:39, Arnaud Rebillout wrote:
I've prepared an update for systemd, two questions:
1) Given that severity of CVE-2026-29111 is higher <= bullseye (stack
overwrite), I suppose I won't wait for the fix to reach bookworm and
can upload straight away (after debusine workflow completes) ?
This is quite rare but yes this makes sense to upload a fix for
CVE-2026-29111 promptly.
Besides debusine, what kind of testing (automated and manual) did you
perform?
There's a simple python script to reproduce the issue, available at
https://github.com/systemd/systemd/security/advisories/GHSA-gx6q-6f99-m764.
For bookworm it's easy, as it triggers an assert.
However for bullseye, the reproducer doesn't seem to cause any issue, on
the surface. No error or crash. I guess it's expected, the stack
overwrite doesn't necessarily corrupt existing data on the stack, maybe
it just appends data on a unused location (my understanding).
So I did some research, came across the tool gcore. I could dump the
stack before and after calling the reproducer: the size of the dump is
multiplied by 3 after calling the reproducer. And then again after
fixing the CVEs: this time the size of the dump is identical after
calling the reproducer.
More details below if you're curious.
Another possibility is to wait for info regarding new CVEs in the
tracker, that just appeared yesterday, and apparently don't have CVE
number yet (they appear in the tracker as TEMP-XXX). And maybe fix
those as well, before uploading.
Apparently this is sorted out now, but maybe we can schedule another
DLA for these later.
Ok. I'll check if ever the CVE fixes are trivial, by chance.
Not sure what's best here, wait or not wait, opinions welcome :)
2) If anyone wants to have a look and review, would be nice, given
it's an important package. Pushed at:
https://salsa.debian.org/arnaudr/systemd.
There's only a "bookworm-cves" updated branch.
My bad, I had to rename the repo, it's now at
https://salsa.debian.org/arnaudr/systemd-lts. Sorry for the confusion.
Best,
Arnaud
----
Crunchy details: testing the fix for CVE-2026-2911
BEFORE PATCH:
```
root@testvm:~# gcore 1
root@testvm:~# mv core.1 core.orig
root@testvm:~# ./test.py 2>&1 | tr -s A
Traceback (most recent call last):
File "/root/./test.py", line 8, in <module>
obj.GetUnitByControlGroup("/" + "A" * 8000000) # * 10)
File "/usr/lib/python3/dist-packages/pydbus/proxy_method.py", line
72, in __call__
ret = instance._bus.con.call_sync(
gi.repository.GLib.Error: g-io-error-quark:
GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Control group '/A' is
not valid or not managed by this instance (36)
root@testvm:~# gcore 1
root@testvm:~# hexdump -v -C core.orig | grep AAAAAAAA | wc -l
0
root@testvm:~# hexdump -v -C core.1 | grep AAAAAAAA | wc -l
512507
root@testvm:~# ls -lh
total 16M
-rw-r--r-- 1 root root 12M Apr 8 10:03 core.1
-rw-r--r-- 1 root root 3.9M Apr 8 10:02 core.orig
```
AFTER PATCH:
```
root@testvm:~# gcore 1
root@testvm:~# mv core.1 core.orig
root@testvm:~# ./test.py 2>&1 | tr -s A
Traceback (most recent call last):
File "/root/./test.py", line 8, in <module>
obj.GetUnitByControlGroup("/" + "A" * 8000000) # * 10)
File "/usr/lib/python3/dist-packages/pydbus/proxy_method.py", line
72, in __call__
ret = instance._bus.con.call_sync(
gi.repository.GLib.Error: g-dbus-error-quark:
GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Control group path
is not normalized: /A (16)
root@testvm:~# gcore 1
root@testvm:~# hexdump -v -C core.orig | grep AAAAAAAA | wc -l
0
root@testvm:~# hexdump -v -C core.1 | grep AAAAAAAA | wc -l
12658
root@testvm:~# ls -lh
total 7.8M
-rw-r--r-- 1 root root 3.9M Apr 7 16:21 core.1
-rw-r--r-- 1 root root 3.9M Apr 7 16:21 core.orig
```
DIFFERENCES BEFORE/AFTER CVE FIX:
- not the same error message
- size of the core file jumped to 12M after calling the reproducer,
also it has much more `AAAA` lines in it
Reply to: