Consider reintroducing checking of alloca() calls in STACKLEAK

phabricator-migrator · February 19, 2024, 5:23pm

Information

ID: 954
PHID: PHID-TASK-ocolbbw5xegkztqyn47v
Author: madaidan
Status at Migration Time: open
Priority at Migration Time: Normal

Description

github.com/clipos/src_external_linux

stackleak: reintroduce checking of alloca() calls

committed 04:40PM - 07 Nov 18 UTC

tsautereau-anssi

+102 -11

This reintroduces the portion of the STACKLEAK GCC plugin that instruments the k…ernel code by inserting the stackleak_check_alloca() call before alloca(). The goal is to block kernel stack depth overflows caused by alloca() (e.g. Stack Clash). This feature was dropped on STACKLEAK's way to mainline but we are interested in it despite the VLA removal because: - it protects out-of-tree code; - it acts as a failsafe, for instance if VLAs are inadvertently reintroduced. The STACKLEAK feature was ported by Alexander Popov from grsecurity/PaX's code. More information at: https://grsecurity.net/ https://pax.grsecurity.net/ This code is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on our understanding of the code. Changes or omissions from the original code are ours and don't reflect the original grsecurity/PaX code. Change-Id: Iae2fa98ee442bc75731534fe21edc7de26bc00e0 Signed-off-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>

We might want to add this patch to hardened-kernel once our version catches up with STACKLEAK.

This patch was part of the original STACKLEAK patch series sent upstream but it was dropped because all VLAs were removed from the kernel so it had no purpose anymore.

This would only be useful for out-of-tree code (certain kernel modules/patches) or as a fail-safe incase VLAs are reintroduced although that’s unlikely and even more so for an LTS kernel, meaning this patch has likely very little, if any at all, advantage now.

Consider reintroducing checking of alloca() calls in STACKLEAK

Information

Description

Comments