linux-kernel - MIPS ASID type conflicts

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]

Message-ID: <CAEiBgeAukAdZv1WNcJQ6DByP7Yy63gvRS0cY6q6yU27p+XRi4A@mail.gmail.com>
Date:	Mon, 23 Apr 2012 13:49:26 +0200
From:	Jean-Christophe PINCE <jcpince@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: MIPS ASID type conflicts

Hi,

I am analyzing Linux MIPS tasks memory spaces and found out what I
think is a bug in the ASID management.

The structure "struct cpuinfo_mips" defined in
arch/mips/include/asm/cpu-info.h uses a "unsigned int" field for
asid_cache while the context field defined in
arch/mips/include/asm/mmu.h is a "unsigned long".

This is ok with 32bits kernel but leads to 4bytes vs 8bytes fields
with a 64bits kernel. And when the scheduler checks if the ASID is of
an older ASID_VERSION, the test will always return that the version
differs when the context bits above bit31 will be set.

I imagine this should be a quite rare issue but could likely happen on
devices running for very long and starting processes very often (or
running more than 256 processes per cpu). When this condition (bit 32
or above of asid_cache is set), the effect should be that the TLB will
be flushed on each context_switch required by the scheduler but there
shouldn't be any crash.

Hope this helps,
Thanks and regards,
JC
--
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/