And just to confirm tim, we're sorting out the nature of a minimal patch for a possible errata, and we'll need to get the errata signed. I don't anticipate this will be more than a day or two if you can wait that long.
On Mon, Aug 1, 2016 at 1:09 PM, Mark Kettenis <[email protected]> wrote: > > From: Jesse Hertz <[email protected]> > > Date: Mon, 1 Aug 2016 14:38:19 -0400 > > > > Hi All, > > > > Is a fix for this in the works? We'd like to be able to point to a > > fix before posting to oss-sec :) > > Hi Jesse, > > The fix suggested in the analysis has been committed, and we have > committed two other fixes to prevent against overflows/underflows in > related uvm code. Not sure if somebody is doing an errata for -stable > for this. > > CVSROOT: /cvs > Module name: src > Changes by: [email protected] 2016/07/29 14:44:40 > > Modified files: > sys/uvm : uvm_map.c > > Log message: > add a check that the arguments to isavail don't overflow. > callers should probably check too, but checking here won't hurt. > possible panic reported by tim newsham. > ok kettenis > > > CVSROOT: /cvs > Module name: src > Changes by: [email protected] 2016/07/30 10:37:55 > > Modified files: > sys/uvm : uvm_addr.c > > Log message: > Add a few checks for potential integer overflow and underflow related to > the > size of an address range. > > ok deraadt@, tedu@ > > > CVSROOT: /cvs > Module name: src > Changes by: [email protected] 2016/07/30 10:43:44 > > Modified files: > sys/uvm : uvm_map.c > > Log message: > Check for wraparound before the "commit" phase of uvm_map() and > uvm_mapanon(), > to prevent hitting assertions and/or corrupting data structures during that > phase. > > ok deraadt@, tedu@ > > > >
