From 6d28316864a44ea16669de79f2aefab2933fbf3a Mon Sep 17 00:00:00 2001 From: Rob Landley Date: Fri, 6 May 2022 02:58:17 -0500 Subject: [PATCH] Shut up llvm's "fortify" about not checking the fscanf() return value. We already confirm that the sender is another toysh instance (the ppid!=getppid() line), set the variables to zero before reading (which should stay zero if it can't read that field, and len 0 causes the loop to exit), and then we error_exit() if we can't read the requested length. That should handle the sender exiting unexpectedly (probably via signal). Outright malicious data going across the pipe could tell the subshell to "rm -rf ~", that's a "you've already lost" scenario more checks wouldn't help. --- toys/pending/sh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/toys/pending/sh.c b/toys/pending/sh.c index 9c3e3ee7..5379198a 100644 --- a/toys/pending/sh.c +++ b/toys/pending/sh.c @@ -3838,7 +3838,7 @@ static void nommu_reentry(void) // Read named variables: type, len, var=value\0 for (;;) { len = ll = 0; - fscanf(fp, "%u %lu%*[^\n]", &len, &ll); + (void)fscanf(fp, "%u %lu%*[^\n]", &len, &ll); fgetc(fp); // Discard the newline fscanf didn't eat. if (!len) break; (s = xmalloc(len+1))[len] = 0; -- 2.39.2