Bugzilla – Bug 994624
VUL-1: CVE-2016-0821: kernel: LIST_POISON bypass
Last modified: 2020-06-16 09:53:21 UTC
via cve db
The LIST_POISON feature in include/linux/poison.h in the Linux kernel before 4.3, as used in Android 6.0.1 before 2016-03-01, does not properly consider the relationship to the mmap_min_addr value, which makes it easier for attackers to bypass a poison-pointer protection mechanism by triggering the use of an uninitialized list entry, aka Android internal bug 26186802, a different vulnerability than CVE-2015-3636.
in some form even in sles10 2.6.16 kernel and onwards.
Do we really care to patch this one? It is 32b only because 64b moves the poison to 0xdead range. Even then it would apply only to the distributed kernel as it sits in the header files. Linked list use is reduced to the CONFIG_DEBUG_LIST but hlist seems to use it all the time though. But all in all I am not sure this is all that important. What do you think?
bugbot adjusting priority
hmm. sle11 has a 32bit kernel still.
in 3.0.101 i see no seperate handling for 64bit? it always uses these values?
but this is largely a hardening patch, we can discuss if we need it.
(In reply to Marcus Meissner from comment #4)
> hmm. sle11 has a 32bit kernel still.
> in 3.0.101 i see no seperate handling for 64bit? it always uses these values?
It's defined in arch/x86/Kconfig:ILLEGAL_POINTER_VALUE. 64bit has the base 0xdead000000000000 while 32bit has base 0.
> but this is largely a hardening patch, we can discuss if we need it.
Yeah, it's a question...
Basically the usage of poison values in hlist are harmless: the value is nowhere referenced unlike the doubly list debug code. Maybe only for triggering Oops properly.
But my slight concern is that LIST_POISION seem to be used in other codes. A simple grep on SLE11-SP4 tree shows like:
% grep -rl 'LIST_POISON'
So changing the value silently *might* cause some inconsistency.
(In reply to Takashi Iwai from comment #5)
> So changing the value silently *might* cause some inconsistency.
I fully agree! And it just doesn't sound worth for 32b. Can we close this as WONTFIX?
I think we can solve this as WONTFIX and document it
This problem should only affect 32bit kernels, and is a hardening measure and not a direct exploitable issue. We currently do not plan to fix this issue.