[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160717153008.3C3C16C10F9@smtpvmsrv1.mitre.org>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
