linux-kernel - Re: [PATCH] proc: /proc/kpageflags: incorrect arg order in kpf_copy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200903022040.n22KeX20030383@pobox-pa.hpl.hp.com>
Date:	Mon, 02 Mar 2009 12:40:33 -0800
From:	Jeffrey Mogul <Jeff.Mogul@...com>
To:	Alexey Dobriyan <adobriyan@...il.com>
cc:	Jeffrey Mogul <Jeff.Mogul@...com>, linux-kernel@...r.kernel.org,
	stable@...nel.org
Subject: Re: [PATCH] proc: /proc/kpageflags: incorrect arg order in kpf_copy_bits()

    On Fri, Feb 27, 2009 at 05:56:39PM -0800, Jeffrey Mogul wrote:
    > The code in fs/proc/page.c that implements /proc/kpageflags has

    Already fixed in mainline:

    commit e07a4b9217d1e97d2f3a62b6b070efdc61212110
    Author: Helge Bahmann <helge.bahmann@...unet.com>
    Date:   Fri Feb 20 16:24:12 2009 +0300

        proc: fix PG_locked reporting in /proc/kpageflags

        Expr always evaluates to zero.

Unfortunately, I think that only fixes one of the two bugs
I reported.  The other one is that the argument order for the
kpf_copy_bits macro definition does not match the arg order
for all of the uses (including the one that was already "fixed").

Thanks
-Jeff

The kpf_copy_bits() macro was defined with argument order
(flags, srcpos, dstpos), which is the logical order, but all
but one of the uses of this macro invoke it instead in the order
(flags, dstpos, srcpos).  This only affects the output for a few
flags, since in most -- but not all! -- cases, srcpos == dstpos.

I fixed this by changing the macro definition rather than the macro
uses, which minimizes the number of lines to change but which might
not be the most obvious/logical design.

These bugs appear to have been in the code since /proc/kpageflags
was introduced (2.6.25).

CC: stable@...nel.org
Signed-off-by: Jeff Mogul <Jeff.Mogul@...com>
---

--- linux-2.6.28.7/fs/proc/page.c.orig  2009-02-26 17:16:42.000000000 -0800
+++ linux-2.6.28.7/fs/proc/page.c       2009-02-26 17:18:04.000000000 -0800
@@ -80,7 +80,8 @@ static const struct file_operations proc
 #define KPF_RECLAIM    9
 #define KPF_BUDDY     10

-#define kpf_copy_bit(flags, srcpos, dstpos) (((flags >> srcpos) & 1) << dstpos)
+/* Arg order is dstpos,srcpos because that's how this macro is used below */
+#define kpf_copy_bit(flags, dstpos, srcpos) (((flags >> srcpos) & 1) << dstpos)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/