Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 659567 - (CVE-2010-4258) CVE-2010-4258 kernel: failure to revert address limit override in OOPS error path
CVE-2010-4258 kernel: failure to revert address limit override in OOPS error ...
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 659568 659569 659570 659571 659572 659573 659574
  Show dependency treegraph
Reported: 2010-12-02 21:04 EST by Eugene Teo (Security Response)
Modified: 2016-08-18 10:07 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-07-29 09:28:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2010-12-02 21:04:48 EST
Nelson discovered an interesting interaction in the Linux kernel between the clear_child_tid feature of clone(2), and the set_fs() function used internally in the kernel to temporarily disable access_ok() checking of userspace pointers.

Under some (not totally uncommon) circumstances, it is possible for a user to leverage this interaction to turn a kernel oops or BUG() into a write of an integer 0 to a user-controlled address in kernel memory.

This is known to be exploited with CVE-2010-3849 - http://www.redhat.com/security/data/cve/CVE-2010-3849.html.


Red Hat would like to thank Nelson Elhage for reporting this issue.
Comment 2 Eugene Teo (Security Response) 2010-12-05 21:49:06 EST
This needs oops to first trigger the mm_release path with set_fs(KERNEL_DS) and invoke put_user(0, tsk->clear_child_tid). We have panic_on_oops set on rhel so this is not exploitable because mm_release will not get called and the box panics.
Comment 4 Eugene Teo (Security Response) 2010-12-05 21:58:58 EST

The Linux kernel as shipped with Red Hat Enterprise Linux 4, 5, 6, and Red Hat Enterprise MRG enabled the panic_on_oops sysctl tunable by default, and therefore are not affected by this issue. However, as a preventive measure (for example, for administrators who have turned panic_on_oops off), this issue was fixed in kernel updates in Red Hat Enterprise Linux 4, 5, 6, and Red Hat Enterprise MRG. Because the fix was considered as a preventative measure, this CVE is not listed in the related advisories that provided the fix: RHSA-2011:0162, RHSA-2011:0263, RHSA-2011:0017, RHSA-2011:0498, RHSA-2011:0542, RHSA-2011:0330. The fix is documented in each of these advisories as a regular bug fix, for example as BZ#659568 in RHSA-2011:0162.

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