predictions: the script kiddies will figure out that there are other SUID freedesktop.org softwares which use GLib. the distros which install my execve(2) patch will sleep happy at night, the ones who don't will spend the next few weeks playing whack a mole.
Conversation
Yeah but that's a given, there's never a situation where they aren't 😛
1
4
Waiting for a prominent case where one of their contract-breaking "hardening" hacks makes an important piece of software vulnerable. 😁
1
1
honestly that’s more grsec world. the openbsd guys have always been thoughtful about not breaking shit in my experiences anyway
3
6
Size overflow has a lot of false positives due to or intended or unintended but benign integer overflows and could cause DoS issues but you know what you're getting when you choose to enable it.
If you're using RBAC or enforcing MPROTECT/TPE you also know what you're getting.
1
Doesn't really break much unless you ask for it by enforcing that programs can't execute dynamically generated code in-memory (MPROTECT) or the similar guarantees provided by TPE for storage.
There are only a few minor changes which can break programs doing very strange things.
1
There are slight differences for ASLR, mmap hints, the main thread stack mapping and secondary stack mappings. It usually doesn't cause issues and that's all standards compliant.
Some programs assume hints will work without using MAP_FIXED/MAP_FIXED_NOREPLACE and infinite loop.
I can think of a few cases where they change how Linux APIs work such as the setxid feature which primarily just makes setuid, etc. POSIX compliant in the kernel instead of requiring libc, etc. to hack around it. Fixes issues like this past 9 year bug:
1
Technically breaks Linux API compatibility and I once found a program which was broken by it. They changed the feature to work around it though. I totally forget the details. Android Runtime was also broken by PaX stack mapping changes but upstream broke it a similar way later.