[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ddcd920ff99e0f97ed2c92cf650872d76a4b7404ea87a104e6ab061ee3005cf9@mail.kernel.org>
Date: Thu, 20 Nov 2025 00:32:34 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: david.laight.linux@...il.com,linux-kernel@...r.kernel.org,netdev@...r.kernel.org
Cc: dsahern@...nel.org,davem@...emloft.net,edumazet@...gle.com,kuba@...nel.org,pabeni@...hat.com,david.laight.linux@...il.com,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCH 09/44] ipv6: __ip6_append_data() don't abuse max_t() casts
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index f904739e9..6fecf2f2c 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -1440,7 +1440,7 @@ static int __ip6_append_data(struct sock *sk,
> struct sk_buff *skb, *skb_prev = NULL;
> struct inet_cork *cork = &cork_full->base;
> struct flowi6 *fl6 = &cork_full->fl.u.ip6;
> - unsigned int maxfraglen, fragheaderlen, mtu, orig_mtu, pmtu;
> + unsigned int maxfraglen, fragheaderlen, mtu, orig_mtu;
[ ... ]
> @@ -1504,9 +1504,10 @@ static int __ip6_append_data(struct sock *sk,
> maxnonfragsize = mtu;
>
> if (cork->length + length > maxnonfragsize - headersize) {
> + int pmtu;
> emsgsize:
> - pmtu = max_t(int, mtu - headersize + sizeof(struct ipv6hdr), 0);
> - ipv6_local_error(sk, EMSGSIZE, fl6, pmtu);
> + pmtu = mtu - headersize + (int)sizeof(struct ipv6hdr);
> + ipv6_local_error(sk, EMSGSIZE, fl6, max(pmtu, 0));
> return -EMSGSIZE;
> }
Can the variable pmtu be used uninitialized here?
When reaching the emsgsize label via goto statements from earlier in
__ip6_append_data() (the checks at lines around mtu <= fragheaderlen,
headersize + transhdrlen > mtu, and the dontfrag check), the int pmtu
declaration is skipped. This leaves pmtu uninitialized when it's used
in the calculation that's passed to ipv6_local_error().
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/19519124312
Powered by blists - more mailing lists