linux-kernel - [PATCH 0/2] x86 vdso 32-bit vdso-disabling fixes

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:	Wed,  9 Apr 2008 01:27:03 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>
Cc:	Amnon Shiloh <u3557@...o.sublimeip.com>,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] x86 vdso 32-bit vdso-disabling fixes

These two patches together address two potential bugs when trying to
disable the 32-bit vDSO via sysctl or boot parameters (vdso32=0).

Currently, every 32-bit exec gets the vDSO mapped even if it's disabled
(the process just doesn't get told about it).  Because it's in fact
always there, the bug that patch 1/2 fixes cannot happen now.  With
patch 2/2, it won't be mapped at all when it's disabled, which is one
of the things that people might really want when they disable it (so
nothing they didn't ask for goes into their address space).

The 32-bit signal handler setup when SA_RESTORER is not used refers to
current->mm->context.vdso without regard to whether the vDSO has been
disabled when the process was exec'd.  Patch 1/2 fixes this not to use
it when it's null, which becomes possible after patch 2/2.  (This never
happens in normal use, because glibc's sigaction call uses SA_RESTORER
unless glibc detected the vDSO.)

Thanks,
Roland
--
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/