Re: Multiple Bugs in OpenBSD Kernel

[cve-assign () mitre org]

-----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-----