[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <daabe69d3863caa62f7874a472edbf2bc892d99e.camel@codeconstruct.com.au>
Date: Tue, 15 Feb 2022 08:44:57 +0800
From: Jeremy Kerr <jk@...econstruct.com.au>
To: trix@...hat.com, matt@...econstruct.com.au, davem@...emloft.net,
kuba@...nel.org, nathan@...nel.org, ndesaulniers@...gle.com
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH] mctp: fix use after free
Hi Tom,
> Clang static analysis reports this problem
> route.c:425:4: warning: Use of memory after it is freed
> trace_mctp_key_acquire(key);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> When mctp_key_add() fails, key is freed but then is later
> used in trace_mctp_key_acquire(). Add an else statement
> to use the key only when mctp_key_add() is successful.
Looks good to me, thanks for the fix.
However, the Fixes tag will need an update; at the point of
4a992bbd3650 ("mctp: Implement message fragmentation"), there was no
use of 'key' after the kfree() there.
Instead, this is the hunk that introduced the trace event:
@@ -365,12 +368,16 @@
if (rc)
kfree(key);
+ trace_mctp_key_acquire(key);
+
/* we don't need to release key->lock on exit */
key = NULL;
- which is from 4f9e1ba6de45. The unref() comes in later, but the
initial uaf is caused by this change.
So, I'd suggest this instead:
Fixes: 4f9e1ba6de45 ("mctp: Add tracepoints for tag/key handling")
(this just means we need the fix for 5.16+, rather than 5.15+).
Also, can you share how you're doing the clang static analysis there?
I'll get that included in my checks too.
Cheers,
Jeremy
Powered by blists - more mailing lists