linux-kernel - [RFC PATCH] gpio: pl061: handle failed allocations

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: <1543665438-26756-1-git-send-email-hofrat@osadl.org>
Date:   Sat,  1 Dec 2018 12:57:18 +0100
From:   Nicholas Mc Guire <hofrat@...dl.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Russell King <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Nicholas Mc Guire <hofrat@...dl.org>
Subject: [RFC PATCH] gpio: pl061: handle failed allocations

devm_kzalloc(), devm_kstrdup() and devm_kasprintf() all can
fail internal allocation and return NULL. Using any of the assigned
objects without checking is not safe. As this is early in the boot
phase and these allocations really should not fail, any failure here
is probably an indication of a more serious issue so it makes little
sense to try and rollback the previous allocated resources or try to
continue;  but rather the probe function is simply exited with -ENOMEM.

Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
Fixes: 684284b64aae ("ARM: integrator: add MMCI device to IM-PD1")
---

devm_kstrdup() issue found by experimental coccinelle script, the rest during
review of the reported issue.

Q: Not sure if brute force returning here without rollback of previously
   allocated resources is acceptable - but I guess if any of those
   allocations failed the system is doomed anyway so trying a  continue;
   here does not seem sensible to me.

While at it switched the kasprintf to the managed API variant - or should
this be done in a separate patch ?

Patch was compile tested with: multi_v4t_defconfig (implies
INTEGRATOR_IMPD1=y)

Patch is against 4.20-rc4 (localversion-next is next-20181130)

 arch/arm/mach-integrator/impd1.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index a109f648..0f916c2 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -393,7 +393,11 @@ static int __ref impd1_probe(struct lm_device *dev)
 					      sizeof(*lookup) + 3 * sizeof(struct gpiod_lookup),
 					      GFP_KERNEL);
 			chipname = devm_kstrdup(&dev->dev, devname, GFP_KERNEL);
-			mmciname = kasprintf(GFP_KERNEL, "lm%x:00700", dev->id);
+			mmciname = devm_kasprintf(&dev->dev, GFP_KERNEL,
+						  "lm%x:00700", dev->id);
+			if (!lookup || !chipname || !mmciname)
+				return -ENOMEM;
+
 			lookup->dev_id = mmciname;
 			/*
 			 * Offsets on GPIO block 1:
-- 
2.1.4