Date: Tue, 14 Apr 2015 02:21:41 -0400 (EDT) From: cve-assign@...re.org To: pierre@...ctos.org Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Kernel oops on 32 bits arch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > This bug report has been brought to my attention  where under high > load a server can be oopsed, be it grsec or vanilla kernel. > > Apparently, it's due to a partial fix that would have only be deployed > to 64 bits Linux . > > Has anyone more info on this? Like why there was only a 64 bits fix? > Was a CVE assigned for this? > > : https://bugs.gentoo.org/show_bug.cgi?id=536040 > : https://lkml.org/lkml/2014/4/29/497 As far as we can tell, https://lkml.org/lkml/2014/4/29/497 ultimately resulted in the http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d5c9fde3dae750889168807038243ff36431d276 commit. https://bugs.gentoo.org/show_bug.cgi?id=536040#c20 says so we think it's an upstream bug https://lkml.org/lkml/2014/4/29/497 that was fixed only on 64 bit archs. on 32 bit archs the function in question uses a 32 bit type (unsigned long) instead of u64 and therefore the trunction issue mentioned in the thread can very well happen. This suggests that the same source code is used on all platforms, but the code with the d5c9fde3dae750889168807038243ff36431d276 patch is correct if the size of "unsigned long" is 8, but incorrect if the size of "unsigned long" is 4. (There isn't a patch offered for the latter case, although the implication seems to be that the code is inherently incorrect, and isn't affected by any compiler bug.) If so, then conceivably there could be at least two CVE IDs, i.e., First issue: reachable "divide by zero" in versions before 3.14.6 on 64-bit platforms (https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.14.6) Second issue: reachable "divide by zero" in these versions and newer versions on 32-bit platforms [ there hasn't been a report of a security impact for the "incorrect value when (setpoint - limit) exceeds 2^32" issue ] The available information about the attack vector for the second issue is "unspecified traffic to an Apache HTTP Server 2.x that leads to a substantial amount of disk I/O to an ext4 filesystem." There is no available information about an attack vector for the first issue. We don't know whether there are other attack vectors involving FUSE. The comments in page-writeback.c refer to the effects of "mistrusted filesystems" on the number of dirty pages, and possibly such a filesystem could make it easier to reach a case with a pos_ratio_polynom bug. In general, the two issues listed above are ones that often would not have CVE IDs because the attack methodology is underspecified, or because too little is known about the relationship between an attack and the bug. However, it seems very likely that the untrusted HTTP traffic is, indirectly, causing the bug to be triggered much more often than it otherwise would have been. So, it does seem valid for the issues to have CVE IDs, if the CVE IDs are useful to someone. Was "Was a CVE assigned for this?" intended to mean that a CVE ID is useful, i.e., you would actually use a CVE ID to track an OOPS issue in the management of dirty pages? - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJVLLFFAAoJEKllVAevmvmst+QH/jF6SuBJAtxYZX+WYpWkcSwu f8h4dGncGX947++aB0NWVVmD2AlckRkZOdIYL2r2JE9M/2yrHHNq72cAPylYQD// m55DggeJ6mia756FWng9JSV3qf48tNqZq5nAFFZH8OsIG9dlNV4esCqLS0qsYtAo To6LixAVrcFpofzi+q7U8ON0IxfBoix+J1eQoT3ITyRJ+NwnvWX/jLm6jOk/lbSS Q4Wh61+/EQEpxIga3CJ2J3g0pHM20wrSNxMV9Tpgl7vFwWSP9csNsc+XPp4HUZB7 XYwAf6FQWAdYC0WyhzYxqEZP2YIkrd0uhVp0KJdvcj8pRow20/MhCN7Rl7Q8vto= =/Ro0 -----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