Bug 43151 - hugetlb: use after free bug in "quota" handling
hugetlb: use after free bug in "quota" handling
Status: RESOLVED OBSOLETE
Product: Memory Management
Classification: Unclassified
Component: Other
All Linux
: P1 high
Assigned To: Andrew Morton
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-23 13:12 UTC by Shachar Raindel
Modified: 2014-01-10 20:47 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.24-3.3+
Tree: Mainline
Regression: No


Attachments
Example code - will create an oops on a machine running a debug kernel (1.94 KB, application/octet-stream)
2012-04-23 13:12 UTC, Shachar Raindel
Details

Description Shachar Raindel 2012-04-23 13:12:22 UTC
Created attachment 73047 [details]
Example code - will create an oops on a machine running a debug kernel

Description of problem:

There is a use after free bug in the kernel hugetlb code. The bug can allow an
authenticated, unprivileged local attacker to crash the system (and possibly
gain higher privileges) if huge pages are enabled in the system.

A fix has been committed to linux-next, commit
90481622d75715bfcb68501280a917dbfe516029 "hugepages: fix use after free bug in
"quota" handling"

Version-Release number of selected component (if applicable):
The bug exists in kernel versions 2.6.24 and above.


How reproducible:

The attached tarball includes an example code which utilizes a fuse mount with
O_DIRECT flag to reproduce the issue. The code will work only on kernels 2.6.32
and above since it uses the new "anonymous mapping" API for getting huge pages.
Similar reproduction is possible when using the shmem API or the hugetlbfs API. 
Stock kernel might not crash, debug kernel will detect the corruption and kill
the process.

Steps to Reproduce:
1. Untar the attached file
2. Run run_test.sh. The fuse-devel package and sudo rights are required for the
fuse mount. Sudo rights are also required for enabling huge pages.
3. Observe the kernel crash when running debug kernel. Normal kernels will
(usually) not crash, as the slab allocator will not return the memory blocks to
the system general pool for a while.

Actual results:

An oops is printed, and the requesting process is killed (if using debug kernel). Silent memory corruption happens if debug features are disabled.

Expected results:

The process should exit without a kernel oops.

Additional info:

Verified on stock kernel 3.3. Buggy code exists since kernel 2.6.24.

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