Date: Tue, 08 Nov 2016 12:07:38 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 214300] Integer truncation issues lead to out-of-bounds kernel reads and panics in clock_settime(). Message-ID: <bug-214300-8-0qNVoNEyLd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-214300-8@https.bugs.freebsd.org/bugzilla/> References: <bug-214300-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214300 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kib@FreeBSD.org Hardware|amd64 |Any --- Comment #1 from Konstantin Belousov <kib@FreeBSD.org> --- The real problem is that clock_ts_to_ct() does not return an error, which m= eans that an update to the function which returns error sometimes requires simil= ar update to all two dozens of callers, including rare platforms. There are more problems, e.g. typical RTC year register only has three or f= our bcd digits, so that values cannot be stored, but we currently do not check = for that. Due to algorithm of clock_ts_to_ct(), insanely large values would be handled quite long, with the type of local vars fixed. IMO fixing all the issues is relatively large work for almost no benefit. I propose, instead, to limit the range of valid setclock(2) values, by e.g. coarse approximating four bcd digits in the year value. Also, since you already diagnosed and noted it, change the type of the year and days variab= les in clock_ts_to_ct(). I put a sysctl to allow experimentation. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-214300-8-0qNVoNEyLd>