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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ