Bug 994624 - (CVE-2016-0821) VUL-1: CVE-2016-0821: kernel: LIST_POISON bypass
VUL-1: CVE-2016-0821: kernel: LIST_POISON bypass
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P4 - Low : Normal
: ---
Assigned To: Security Team bot
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2016-08-19 14:09 UTC by Marcus Meissner
Modified: 2020-06-16 09:53 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2016-08-19 14:09:05 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. 


Comment 1 Marcus Meissner 2016-08-19 14:10:14 UTC
in some form even in sles10 2.6.16 kernel and onwards.
Comment 2 Michal Hocko 2016-08-19 14:26:43 UTC
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?
Comment 3 Swamp Workflow Management 2016-08-19 22:01:01 UTC
bugbot adjusting priority
Comment 4 Marcus Meissner 2016-08-20 11:22:10 UTC
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.
Comment 5 Takashi Iwai 2016-08-22 12:21:08 UTC
(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[12] seem to be used in other codes.  A simple grep on SLE11-SP4 tree shows like:

% grep -rl 'LIST_POISON[12]'

So changing the value silently *might* cause some inconsistency.
Comment 6 Michal Hocko 2016-08-22 12:29:16 UTC
(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?
Comment 8 Marcus Meissner 2016-08-22 12:37:34 UTC
I think we can solve this as WONTFIX and document it
Comment 10 Marcus Meissner 2016-09-02 13:31:36 UTC
pushing note:

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.