It was discovered that polkit incorrectly handled cookie input. A local attacker could possibly use this issue to cause polkit to crash, resulting in a denial of service, or execute arbitrary code.

Upstream commit 7e122c8a5120c2aae2d9d44a26796dc18f5b677c of polkit contains a regression stack buffer overflow: an unbounded getline() call was replaced in readcookie() in /src/polkitagent/polkitagenthelperprivate.c, wherein fgets() copies bytes verbatim and does not stop at an embedded NUL byte. If the first byte read from stdin is 0x00, buf[0] == '\0' and strlen(buf) returns 0. The expression strlen(buf) - 1 then underflows (sizet)0 - 1 to SIZEMAX, and buf[SIZEMAX] is an out-of-bounds read. On a typical two's-complement 64-bit target the pointer arithmetic wraps modulo 2^64, so in practice this reads buf[-1] - one byte immediately before the stack buffer.

A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly.

A Local Privilege Escalation vulnerability (from any user to root) was found in polkit's pkexec, a SUID-root program that is installed by default on every major Linux distribution.

It was reported that polkit has a bug, that leads to a minor denial of service, or code execution/privilege escalation. The only privilege necessary is ability to send D-Bus messages, not even necessarily directly to polkitd (usually privileged services ask polkitd for authorization based of a client request: client<->D-Bus<->service<->D-Bus<->polkitd); the attacker does not need special polkit status. This bug allows a local user (a person on a multi-user system, or a daemon account after successfully attacking a daemon over the network) to corrupt memory of polkitd. Corrupting polkitd memory can lead to a crash (known to happen), which is a minor DoS: a specific request being handled during the crash will not get a reply, but polkitd will then be automatically started when next polkit request arrives. In general corrupting memory can lead to arbitrary code execution as polkitd (no proof of concept exists but I can see no reason for this to be impossible), controlling polkitd allows the attacker to grant to anyone access to any polkit-controlled service, including the ability to run any command as root via pkexec.

Initially reported in https://bugzilla.redhat.com/showbug.cgi?id=910262 The patches are attached.