Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 16 Apr 2015 11:29:08 +0200
From: Pierre Schweitzer <>
Subject: Re: Kernel oops on 32 bits arch

Hash: SHA256

First of all, thanks for the detailed answer.

My question was to be understood as: for the 64 bits, was it
considered as a security issue? Was it possible to trigger it remotely
to crash a server?
Reading your whole statement, it seems that on 64 bits, the issue was
relatively difficult to catch.

On 32 bits, on the other hand, it seems that there is a possible
attack scenario: huge IOs on an ext4 file system.
Even though, it requires precise knowledge of the architecture due to
the specific prerequisites.

But we cannot exclude that it could be triggered with other FS, and
attempting to trigger it on any server we face shouldn't be that hard.
In the end, this results in DoS and potentially in data corruption: a
kernel panic is never good for data, especially under high IOs...

Should it be then considered as a security issue for 32 bits? While
not for 64 bits?

On 04/14/2015 08:21 AM, wrote:
>> 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 
> 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 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 
> (
> 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?

- -- 
Pierre Schweitzer <>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Version: GnuPG v2


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.