user-triggerable dbus-daemon memory leak caused by CVE-2014-3477 fix
While trying to set up dbus to be able to run tests in AddressSanitizer, I found a memory leak introduced in 2014 when fixing CVE-2014-3477 (fdo#78979). If a caller sends a message to an activatable service, and the service gets auto-started, then the dbus-daemon discovers that the caller is not actually allowed to send the message to the service, it will leak one "permission denied" error.
This is technically a system bus denial of service via resource exhaustion, because someone could spam messages that each activate a service, and let the dbus-daemon leak all those errors. However, it's a weak attack with multiple mitigations, so I'm not sure whether we should treat it as a security vulnerability or just an ordinary bug. @thiago, @walters, @rhabacker: opinions?
Each denied message is logged to the system log, making it a very noisy attack (and it's obvious which uid and even which process to blame)
To leak unbounded amounts of memory quickly, an attacker would need an unbounded number of activatable services that they aren't allowed to contact (but in practice there is a finite number of services)
To leak unbounded amounts of memory slowly, an attacker would need an activatable service, that they aren't allowed to contact, that either: has exit-on-idle behaviour, is remotely crashable, or can otherwise be induced to exit so that it can be reactivated
If you want to trigger swappy performance death or the OOM killer on a general-purpose Linux system, there are almost certainly easier ways!
No pull request because I don't think we can embargo those, but I'll quote the patch in a comment.