Bug 426081 - (CVE-2007-6417) CVE-2007-6417 tmpfs: restore missing clear_highpage (kernels from 2.6.11 up)
CVE-2007-6417 tmpfs: restore missing clear_highpage (kernels from 2.6.11 up)
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20071128,repor...
: Security
Depends On: 426082 426083 428824
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-18 05:51 EST by Jan Lieskovsky
Modified: 2010-12-22 18:34 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-22 18:34:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Upstream patch for this issue (1.50 KB, patch)
2008-08-07 01:27 EDT, Eugene Teo (Security Response)
no flags Details | Diff

  None (edit)
Description Jan Lieskovsky 2007-12-18 05:51:07 EST
Description of problem -- <cite Hugh Dickins>

tmpfs was misconverted to __GFP_ZERO in 2.6.11.  There's an unusual case in
which shmem_getpage receives the page from its caller instead of allocating.
We must cover this case by clear_highpage before SetPageUptodate, as before.

</cite>

More problem details from CVE description: 

The shmem_getpage function (mm/shmem.c) in Linux kernel 2.6.11 through
2.6.23 does not properly allocate memory in some circumstances, which
might allow local users to read sensitive kernel data or cause a
denial of service (crash).

Attaching also link to upstream commit -- contains also patch
provided from Hugh Dickins (see URL). 

More details from communication with Hugh:

<cite>
It's a vulnerability which might allow an attacker to
access data from inside the kernel which should have been zeroed -
in very limited circumstances I'd prefer not to have to devise and
announce. It would also be wrong data, so could for example crash any program
rightly relying on uninitialized static data to be zeroed - in the
unlikely event that its data was coming via this route (in most setups
it never can do, perhaps I'd conclude that's true of all setups).  It
has escaped notice for nearly three years, so it's not a commonplace.
announce.

</cite>
Comment 6 Eugene Teo (Security Response) 2008-08-07 01:24:30 EDT
(In reply to comment #0)
> Description of problem -- <cite Hugh Dickins>
> 
> tmpfs was misconverted to __GFP_ZERO in 2.6.11.  There's an unusual case in
> which shmem_getpage receives the page from its caller instead of allocating.
> We must cover this case by clear_highpage before SetPageUptodate, as before.

http://lkml.org/lkml/2007/11/28/249.

> It's a vulnerability which might allow an attacker to
> access data from inside the kernel which should have been zeroed -
> in very limited circumstances I'd prefer not to have to devise and
> announce. It would also be wrong data, so could for example crash any program
> rightly relying on uninitialized static data to be zeroed - in the
> unlikely event that its data was coming via this route (in most setups
> it never can do, perhaps I'd conclude that's true of all setups).  It
> has escaped notice for nearly three years, so it's not a commonplace.
> announce.

http://lkml.org/lkml/2007/12/12/3
Comment 8 Eugene Teo (Security Response) 2008-08-07 01:27:39 EDT
Created attachment 313666 [details]
Upstream patch for this issue
Comment 13 Vincent Danen 2010-12-22 18:34:33 EST
This was addressed via:

Red Hat Enterprise Linux version 5 (RHSA-2008:0885)

Note You need to log in before you can comment on or make changes to this bug.