linux-kernel - Sparc32: BTFIXUPSET_CALL(pmd_clear, . . .)-related issue in older versions of the kernel

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-next>] [day] [month] [year] [list]

Date:	Sun, 27 May 2012 16:03:50 +0400
From:	Ilya Malakhov <ilmalakhovthefirst@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Sparc32: BTFIXUPSET_CALL(pmd_clear, . . .)-related issue in older
 versions of the kernel

 Hi.

 While analyzing a rather nasty problem with an application running at
sun4m sparc32 hosts with "Fujitsu TurboSparc" and "TI Viking/MXCC"
MMUs, I realized, that as a 4Kb "Page Table" was freed, only the first
element in the corresponding `pmdv[]' array in

typedef struct { unsigned long pmdv[16]; } pmd_t;

was actually cleared, rather than all the 16 ones.

 The reason for that was the use of `BTFIXUPCALL_SWAPO0G0' instead of
`BTFIXUPCALL_NORM' for `pmd_clear' in case of "default" SRMMU (except
for some specific types of SRMMU) during initialization:
 . .
BTFIXUPSET_CALL(pmd_clear, srmmu_pmd_clear, BTFIXUPCALL_SWAPO0G0);
 . .

 That would probably be OK if pmd_t were `struct { unsigned long pmd;
}' as it used to be ten years ago, but seems to be erroneous nowadays,
doesn't it?

 From a user's point of view this leads to poorly diagnosable
problems. E.g., after a series of mmaps and munmaps one may find
himself in a situation, where different virtual addresses are mapped to
the same physical one.

 A recent commit by David Miller, where pmd_clear() is un-btfixupped,
is likely to solve this problem in future versions of the kernel. I
wonder, if any patches for older ones should be expected.

 Thanks,
 Ilya.
--
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/