From ${URL} : An elevation of privilege vulnerability in the libnl library could enable a local malicious application to execute arbitrary code within the context of a privileged process. References: https://android.googlesource.com/platform/external/libnl/+/f0b40192efd1af977564ed6335d42a8bbdaf650a https://github.com/thom311/libnl/issues/124 https://github.com/thom311/libnl/commit/c473d59f972c35c5a7363d52ee6ee1e0792de0f8 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
The Red Hat bug doesn't actually explain how passing invalid arguments could trigger a privilege escalation. Upstream is puzzled[1][2] as to why that got dropped in their lap and has added[3] a simple sanity check for negative values of `attrlen`, noting that users of libnl functions should validate input to libnl to begin with. [1] https://github.com/thom311/libnl/issues/124#issuecomment-273442865 [2] https://github.com/thom311/libnl/issues/124#issuecomment-273528100 [3] https://github.com/thom311/libnl/commit/c473d59f972c35c5a7363d52ee6ee1e0792de0f8
https://bugzilla.redhat.com/show_bug.cgi?id=1414304 points to https://bugzilla.redhat.com/show_bug.cgi?id=1414309 ("Access denied").
I guess there might be a kernel bug that Red Hat is trying to mitigate by doing a sanity check in libnl. But if I can execute malicious code on a system that relies on libnl passing a negative attrlen to the kernel, and libnl is patched to prevent that, then nothing stops me from linking my code against a "vulnerable" version of libnl and avoid the patched libnl.
And now there is [1] which refers to [2] which both _still_ don't explain how using a negative length that shouldn't be negative in a function argument could ever (directly) lead to a privilege elevation. It specifically states that the problem is in Android, so maybe Android was allowing its apps to use libnl functions without checking their input, but Red Hat probably wasn't and shouldn't have worried. Can we move on, now? [1] https://access.redhat.com/security/cve/CVE-2017-0386 [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0386
