Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 17 Jul 2016 11:30:08 -0400 (EDT)
From: cve-assign@...re.org
To: Jesse.Hertz@...group.trust
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, na-disclosure@...group.trust
Subject: Re: Multiple Bugs in OpenBSD Kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> mmap_panic: Malicious calls to mmap() can trigger an allocation panic
> or trigger memory corruption.

> http://seclists.org/oss-sec/2016/q3/att-68/mmap_panic_c.bin

>> When a user provides the __MAP_NOFAULT flag to mmap, the
>> kernel calls amap_alloc() which calls malloc() with a size derived 
>> from the user-passed size. This is called through
>> sys_mmap(), uvm_mmapfile() and uvm_map() without ever
>> validating the user-provided size. This can result in a panic
>> in malloc. For example when requesting a mapping of
>> 0x222.1111.0000 bytes, amap_alloc() will compute that it needs
>> 0x2221.1110 slots and amap_alloc1() will compute that it needs
>> 0x2221.1200 total slots and will call malloc() to allocate
>> 0x2.2211.2000 bytes resulting in a panic of
>> "panic: malloc: allocation too large, type = 98, size = 9161482240".

Use CVE-2016-6239 for this general "too large" issue.


>> Besides causing a panic, the amap_alloc() code can also miscalculate 
>> the allocation size which would cause an undersized allocation in 
>> amap_alloc1(). This could lead to memory corruption later. There are 
>> two causes.

>> First amap_alloc() computes slots from a size_t size into
>> an integer slots variable:
>> If the original size is larger 0x1000.0000.0000 or larger it will
>> result in a truncated value of slots, resulting in an undersized amap.

Use CVE-2016-6240 for this first "miscalculate" issue.


>> The second problem arises in amap_alloc1():
>> The number of slots is rounded up so that the slot entries fill
>> full pages. This rounding up happens in the integer "totalslots"
>> variable, and can overflow the original "slots" value. This
>> can happen when requesting an allocation of size 0xfff.ffff.0000,
>> for example. In this case amap_alloc() computes that
>> 0xffff.fff0 slots are needed and amap_alloc1() computes
>> that zero totalslots are needed, and allocates an amap of zero
>> bytes. If the amap->am_slots, amap->am_bckptr or amap->am_anon
>> fields are later accessed, it can lead to out-of-memory
>> reads and writes on the kernel allocation heap.

Use CVE-2016-6241 for this second "miscalculate" issue.


> kevent_panic: Any user can panic the kernel with the kevent system
> call.

> http://seclists.org/oss-sec/2016/q3/att-68/kevent_panic_c.bin

>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_event.c.diff?r1=1.72&r2=1.73
>> 
>> If the original ident value is overly large, the value of "size" will
>> be correspondingly large, and can trigger an assertion in mallocarray().
>> This can be abused by any user to cause a kernel panic.

Use CVE-2016-6242.


> thrsleep_panic: Any user can panic the kernel with the __thrsleep
> system call.

> http://seclists.org/oss-sec/2016/q3/att-68/thrsleep_panic_c.bin

>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_synch.c?rev=1.132&content-type=text/x-cvsweb-markup
>> 
>>         if (timespeccmp(tsp, &now, <))
>>         ...
>>         if (to_ticks > INT_MAX)
>>             to_ticks = INT_MAX;
>> 
>> This validation is insufficient. Some values of the user-provided
>> tsp can be in the future and still lead to a negative to_ticks value
>> after conversion. This condition triggers a panic in timeout_add 

Use CVE-2016-6243.


> thrsigdivert_panic: Any user can panic the kernel with the
> __thrsigdivert system call.

> http://seclists.org/oss-sec/2016/q3/att-68/thrsigdivert_panic_c.bin

>>         if (ts.tv_nsec < 0 || ts.tv_nsec >= 1000000000)
>>             timeinvalid = 1;
>>         ...
>>             if (to_ticks > INT_MAX)
>>                 to_ticks = INT_MAX;
>> 
>> 
>> This validation is insufficient. Some values of the user-provided
>> ts can lead to a negative to_ticks value after conversion. This 
>> condition triggers a panic in timeout_add

Use CVE-2016-6244.


> ufs_getdents_panic: Any user can panic the kernel with the getdents
> system call.

> http://seclists.org/oss-sec/2016/q3/att-68/ufs_getdents_panic_c.bin

>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/ufs/ufs/ufs_vnops.c.diff?r1=1.128&r2=1.129
>> 
>> By providing an overly
>> large size, a caller can trigger a panic in the kernel
>> of "malloc: allocation too large" or "out of space in kmem_map".

Use CVE-2016-6245.


> mount_panic: Root users, or users on systems with kern.usermount set
> to true, can trigger a kernel panic when mounting a tmpfs filesystem.

> http://seclists.org/oss-sec/2016/q3/att-68/mount_panic_c.bin

>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/tmpfs/tmpfs_vfsops.c.diff?r1=1.8&r2=1.9
>> 
>> The tmpfs filesystem allows the mounting user to specify a
>> username, a groupname or a device name for the root node of
>> the filesystem. A user that specifies a value of VNOVAL for
>> any of these fields will trigger an assert in tmpfs_alloc_node

Use CVE-2016-6246.


> unmount_panic: Root users, or users on systems with kern.usermount set
> to true, can trigger a kernel panic when unmounting a filesystem.

> http://seclists.org/oss-sec/2016/q3/att-68/unmount_panic_c.bin

>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/vfs_syscalls.c.diff?r1=1.261&r2=1.262
>> 
>> When the unmount system call is called with the MNT_DOOMED flag
>> set, it does not sync vnodes. This can lead to a condition where
>> there is still a vnode on the mnt_vnodelist, which triggers a
>> panic in dounmount

Use CVE-2016-6247.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXi6P4AAoJEHb/MwWLVhi2mOEP/08xXUSqCwZYw3SIDVtaR0Uz
UJuvIKakjyuG0IBHUfOuZO1pdw15fj64UwuVF3vR4PAsMVYDp2N8iCSUa1OUHQ3Z
qXQBqKsnunzk9Vz11Qkehju+rBJf10W0DxWW65MONwjWOKnzMghPCx0NRGGo/iP8
usKpb2kOy9BIH1hGKl+MxUlKVf6x2sMoXLvaEab9TTY45MUB9iPmQ8sfrZokPu9D
PCG2zq9/cZ8wnNdMU7kyfsjUMV8glPl4gw1NLehnuxyjD+qLAWkzL6CCPR441v8N
9J+LCylCnaO/ucJghDnf7U2LkDioevPDSeRpR+SmGSO/2hha7P1mdvApuYHjUxso
Tg5Ii17EwaVlGsWQr1Hmd8WeQmRb23N5PmpEATBdWi/kUTImEIBJ0JvrfNhIwEEs
JD3BSrBGHvQtFAnAQtBsB2TgNGHveqhCMxKHeDvuJojnKRpdElwI2WlflKJ08Z4T
LZcrMrmMSlbFHwgO7aG6XikTtu7mvjSoiAn0Qd9iKod4b1V55WnjzIf0sWFrZtg/
WCi/i07pG+AxlV9AFJdP9WnjAVd/BCehAWt6K7gPsP1IN/xrK53X2b7H+KA46zEB
F3ADwW8W3gPz7bsQDAf7R6kY6CHYFk2lSFOf4tXCLRi4qoyoqiJNr6zv5odSm/0w
eNbK0SxfchFOCL0QvP/D
=gRCL
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ