https://github.com/torvalds/linux
Revision 462e635e5b73ba9a4c03913b77138cd57ce4b050 authored by Tavis Ormandy on 09 December 2010, 14:29:42 UTC, committed by Linus Torvalds on 15 December 2010, 20:30:36 UTC
The install_special_mapping routine (used, for example, to setup the
vdso) skips the security check before insert_vm_struct, allowing a local
attacker to bypass the mmap_min_addr security restriction by limiting
the available pages for special mappings.

bprm_mm_init() also skips the check, and although I don't think this can
be used to bypass any restrictions, I don't see any reason not to have
the security check.

  $ uname -m
  x86_64
  $ cat /proc/sys/vm/mmap_min_addr
  65536
  $ cat install_special_mapping.s
  section .bss
      resb BSS_SIZE
  section .text
      global _start
      _start:
          mov     eax, __NR_pause
          int     0x80
  $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s
  $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o
  $ ./install_special_mapping &
  [1] 14303
  $ cat /proc/14303/maps
  0000f000-00010000 r-xp 00000000 00:00 0                                  [vdso]
  00010000-00011000 r-xp 00001000 00:19 2453665                            /home/taviso/install_special_mapping
  00011000-ffffe000 rwxp 00000000 00:00 0                                  [stack]

It's worth noting that Red Hat are shipping with mmap_min_addr set to
4096.

Signed-off-by: Tavis Ormandy <taviso@google.com>
Acked-by: Kees Cook <kees@ubuntu.com>
Acked-by: Robert Swiecki <swiecki@google.com>
[ Changed to not drop the error code - akpm ]
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent 0fcdcfb
Raw File
Tip revision: 462e635e5b73ba9a4c03913b77138cd57ce4b050 authored by Tavis Ormandy on 09 December 2010, 14:29:42 UTC
install_special_mapping skips security_file_mmap check.
Tip revision: 462e635
pm_qos_interface.txt
PM Quality Of Service Interface.

This interface provides a kernel and user mode interface for registering
performance expectations by drivers, subsystems and user space applications on
one of the parameters.

Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
initial set of pm_qos parameters.

Each parameters have defined units:
 * latency: usec
 * timeout: usec
 * throughput: kbs (kilo bit / sec)

The infrastructure exposes multiple misc device nodes one per implemented
parameter.  The set of parameters implement is defined by pm_qos_power_init()
and pm_qos_params.h.  This is done because having the available parameters
being runtime configurable or changeable from a driver was seen as too easy to
abuse.

For each parameter a list of performance requests is maintained along with
an aggregated target value.  The aggregated target value is updated with
changes to the request list or elements of the list.  Typically the
aggregated target value is simply the max or min of the request values held
in the parameter list elements.

From kernel mode the use of this interface is simple:

handle = pm_qos_add_request(param_class, target_value):
Will insert an element into the list for that identified PM_QOS class with the
target value.  Upon change to this list the new target is recomputed and any
registered notifiers are called only if the target value is now different.
Clients of pm_qos need to save the returned handle.

void pm_qos_update_request(handle, new_target_value):
Will update the list element pointed to by the handle with the new target value
and recompute the new aggregated target, calling the notification tree if the
target is changed.

void pm_qos_remove_request(handle):
Will remove the element.  After removal it will update the aggregate target and
call the notification tree if the target was changed as a result of removing
the request.


From user mode:
Only processes can register a pm_qos request.  To provide for automatic
cleanup of a process, the interface requires the process to register its
parameter requests in the following way:

To register the default pm_qos target for the specific parameter, the process
must open one of /dev/[cpu_dma_latency, network_latency, network_throughput]

As long as the device node is held open that process has a registered
request on the parameter.

To change the requested target value the process needs to write an s32 value to
the open device node.  Alternatively the user mode program could write a hex
string for the value using 10 char long format e.g. "0x12345678".  This
translates to a pm_qos_update_request call.

To remove the user mode request for a target value simply close the device
node.



back to top