Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Apr 2015 02:21:41 -0400 (EDT)
Subject: Re: Kernel oops on 32 bits arch

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]:
> [2]:

As far as we can tell, ultimately
resulted in the
commit. says

  so we think it's an upstream bug
  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

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

  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 ]
Version: GnuPG v1.4.14 (SunOS)


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.