Bug 679261

Summary: [RFE] kernel: kptr_restrict for hiding kernel pointers from unprivileged users [rhel-5.8]
Product: Red Hat Enterprise Linux 5 Reporter: Eugene Teo (Security Response) <eteo>
Component: kernelAssignee: Jiri Pirko <jpirko>
Status: CLOSED WONTFIX QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.8CC: airlied, dhoward, jarod, jpirko, jwest, lwang, plyons, qcai, rkhan, security-response-team
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 679262 679263 (view as bug list) Environment:
Last Closed: 2012-05-07 19:12:31 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:    
Bug Blocks: 679262, 679263    

Description Eugene Teo (Security Response) 2011-02-22 04:36:50 UTC
Description of problem:
Add the %pK printk format specifier and the /proc/sys/kernel/kptr_restrict sysctl.
    
The %pK format specifier is designed to hide exposed kernel pointers, specifically via /proc interfaces.  Exposing these pointers provides an easy target for kernel write vulnerabilities, since they reveal the locations of writable structures containing easily triggerable function pointers.  The behavior of %pK depends on the kptr_restrict sysctl.
    
If kptr_restrict is set to 0, no deviation from the standard %p behavior occurs.  If kptr_restrict is set to 1, the default, if the current user (intended to be a reader via seq_printf(), etc.) does not have CAP_SYSLOG (currently in the LSM tree), kernel pointers using %pK are printed as 0's. If kptr_restrict is set to 2, kernel pointers using %pK are printed as 0's regardless of privileges.  Replacing with 0's was chosen over the default "(null)", which cannot be parsed by userland %p, which expects "(nil)".

Upstream commit:
http://git.kernel.org/linus/455cd5ab305c90ffc422dd2e0fb634730942b257

Also backport:
drm: do not leak kernel addresses via /proc/dri/*/vma
http://git.kernel.org/linus/01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3

timer debug: Hide kernel addresses via %pK in /proc/timer_list
http://git.kernel.org/linus/f590308536db432e4747f562b29e5858123938e9

[PATCH v2] use %pK for /proc/kallsyms and /proc/modules
http://marc.info/?l=linux-kernel&m=129608894604282&w=2 (not upstream yet)

Comment 3 Eugene Teo (Security Response) 2011-04-05 01:18:05 UTC
> [PATCH v2] use %pK for /proc/kallsyms and /proc/modules
> http://marc.info/?l=linux-kernel&m=129608894604282&w=2 (not upstream yet)

http://git.kernel.org/linus/9f36e2c448007b54851e7e4fa48da97d1477a175

Comment 5 RHEL Program Management 2011-06-20 22:34:17 UTC
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update.

Contact your manager or support representative in case you need to escalate this bug.

Comment 6 RHEL Program Management 2012-01-09 14:20:00 UTC
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.8 and Red Hat does not plan to fix this issue the currently developed update.

Contact your manager or support representative in case you need to escalate this bug.

Comment 7 Rashid Khan 2012-05-07 19:12:31 UTC
Due to resource constraints or complexity, this issue could not be resolved in
the time frame of this release.
Kindly please try RHEL 6.3 Beta or 5.8 and see if the problem still happens in that
release. If it does please start a new bug. 
If you feel you cannot move to that release, please contact your Global Support
Specialist for further escalation and prioritization. 
Kind Regards.