OpenBSD Journal

Errata and patches released!

Contributed by grey on from the fuzz testers at work dept.

Now would be a good time to check http://www.openbsd.org/errata59.html as a number of patches related to reliability and security have been released as follows.

This appears to be in response to fuzz testing as documented further in this mailing list archive: http://marc.info/?l=oss-security&m=146853062403622&w=2

Tim Newsham and Jesse Hertz of NCC Group appear to have done most of the research related to these discoveries so far, and I know at least one of them has had patches committed to the OpenBSD project in the past, so it is nice to see continual collaboration from professional researchers contributing back to project! Again, please check http://www.openbsd.org/errata59.html for links to source code patches to address these issues. Excerpted summaries of the issues discovered below:

013: RELIABILITY FIX: July 14, 2016 All architectures Splicing sockets in a loop could cause a kernel spin.

014: RELIABILITY FIX: July 14, 2016 All architectures Multiple processes exiting with a fd-passing control message on a shared socket could crash the system.

015: RELIABILITY FIX: July 14, 2016 All architectures ufs_readdir failed to limit size of memory allocation, leading to panics.

016: SECURITY FIX: July 14, 2016 All architectures The mmap extension __MAP_NOFAULT could overcommit resources and crash the system.

017: RELIABILITY FIX: July 14, 2016 All architectures A race occuring in the unlocked ARP input path can lead to a kernel NULL dereference.

018: RELIABILITY FIX: July 14, 2016 All architectures Tick counting overflows could cause a kernel crash.

019: RELIABILITY FIX: July 14, 2016 All architectures Invalid file descriptor use with kevent(2) could lead to a kernel crash.

020: RELIABILITY FIX: July 14, 2016 All architectures Unchecked parameters and integer overflows in the amap allocation routines could cause malloc(9) to either not allocate enough memory, leading to memory corruption, or to trigger a "malloc: allocation too large" panic.

(Comments are closed)


Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]