On Thu, 11 Nov 2021 19:06:18 -0500 Jon Maloy wrote: > On 11/11/21 15:59, Tadeusz Struk wrote: > > kmemdup can return a null pointer so need to check for it, otherwise > > the null key will be dereferenced later in tipc_crypto_key_xmit as > > can be seen in the trace [1]. > > [1] https://syzkaller.appspot.com/bug?id=bca180abb29567b189efdbdb34cbf7ba851c2a58 > > > > Reported-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > > Signed-off-by: Tadeusz Struk <tadeusz.struk@xxxxxxxxxx> > > --- > > net/tipc/crypto.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c > > index dc60c32bb70d..988a343f9fd5 100644 > > --- a/net/tipc/crypto.c > > +++ b/net/tipc/crypto.c > > @@ -597,6 +597,11 @@ static int tipc_aead_init(struct tipc_aead **aead, struct tipc_aead_key *ukey, > > tmp->cloned = NULL; > > tmp->authsize = TIPC_AES_GCM_TAG_SIZE; > > tmp->key = kmemdup(ukey, tipc_aead_key_size(ukey), GFP_KERNEL); > > + if (!tmp->key) { > > + free_percpu(tmp->tfm_entry); > > + kfree_sensitive(tmp); > > + return -ENOMEM; > > + } > Acked-by: Jon Maloy <jmaloy@xxxxxxxxxx> Hm, shouldn't we free all the tfm entries here?
