Skip to main content

Browse the archive

https://github.com/torvalds/linux
23 October 2021, 00:29:24 UTC
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 
install_special_mapping skips security_file_mmap check.
 
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
ide-tape.txt 
IDE ATAPI streaming tape driver.

This driver is a part of the Linux ide driver.

The driver, in co-operation with ide.c, basically traverses the
request-list for the block device interface. The character device
interface, on the other hand, creates new requests, adds them
to the request-list of the block device, and waits for their completion.

The block device major and minor numbers are determined from the
tape's relative position in the ide interfaces, as explained in ide.c.

The character device interface consists of the following devices:

ht0		major 37, minor 0	first  IDE tape, rewind on close.
ht1		major 37, minor 1	second IDE tape, rewind on close.
...
nht0		major 37, minor 128	first  IDE tape, no rewind on close.
nht1		major 37, minor 129	second IDE tape, no rewind on close.
...

The general magnetic tape commands compatible interface, as defined by
include/linux/mtio.h, is accessible through the character device.

General ide driver configuration options, such as the interrupt-unmask
flag, can be configured by issuing an ioctl to the block device interface,
as any other ide device.

Our own ide-tape ioctl's can be issued to either the block device or
the character device interface.

Maximal throughput with minimal bus load will usually be achieved in the
following scenario:

     1.	ide-tape is operating in the pipelined operation mode.
     2.	No buffering is performed by the user backup program.

Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.

Here are some words from the first releases of hd.c, which are quoted
in ide.c and apply here as well:

| Special care is recommended.  Have Fun!

Possible improvements:

1. Support for the ATAPI overlap protocol.

In order to maximize bus throughput, we currently use the DSC
overlap method which enables ide.c to service requests from the
other device while the tape is busy executing a command. The
DSC overlap method involves polling the tape's status register
for the DSC bit, and servicing the other device while the tape
isn't ready.

In the current QIC development standard (December 1995),
it is recommended that new tape drives will *in addition*
implement the ATAPI overlap protocol, which is used for the
same purpose - efficient use of the IDE bus, but is interrupt
driven and thus has much less CPU overhead.

ATAPI overlap is likely to be supported in most new ATAPI
devices, including new ATAPI cdroms, and thus provides us
a method by which we can achieve higher throughput when
sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
back to top