Bug 426081 (CVE-2007-6417)

Summary: CVE-2007-6417 tmpfs: restore missing clear_highpage (kernels from 2.6.11 up)
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dhoward, jpirko, kreilly, lwang, lwoodman
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-12-22 23:34:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 426082, 426083, 428824    
Bug Blocks:    
Attachments:
Description Flags
Upstream patch for this issue none

Description Jan Lieskovsky 2007-12-18 10:51:07 UTC
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 05:24:30 UTC
(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 05:27:39 UTC
Created attachment 313666 [details]
Upstream patch for this issue

Comment 13 Vincent Danen 2010-12-22 23:34:33 UTC
This was addressed via:

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