[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150414062141.CE1CE6C4009@smtpvmsrv1.mitre.org>
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 [1] 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 [2].
>
> Has anyone more info on this? Like why there was only a 64 bits fix?
> Was a CVE assigned for this?
>
> [1]: https://bugs.gentoo.org/show_bug.cgi?id=536040
> [2]: 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
