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
| ||
|
Message-ID: <4654.1559061019@warthog.procyon.org.uk> Date: Tue, 28 May 2019 17:30:19 +0100 From: David Howells <dhowells@...hat.com> To: Geert Uytterhoeven <geert@...ux-m68k.org> Cc: dhowells@...hat.com, Igor Konopko <igor.j.konopko@...el.com>, "Mohit P . Tahiliani" <tahiliani@...k.edu.in>, Takashi Sakamoto <o-takashi@...amocchi.jp>, Eran Ben Elisha <eranbe@...lanox.com>, Matias Bjorling <mb@...htnvm.io>, Jiri Pirko <jiri@...lanox.com>, "David S . Miller" <davem@...emloft.net>, Jamal Hadi Salim <jhs@...atatu.com>, Cong Wang <xiyou.wangcong@...il.com>, Clemens Ladisch <clemens@...isch.de>, Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Joe Perches <joe@...ches.com>, Arnd Bergmann <arnd@...db.de>, Dan Carpenter <dan.carpenter@...cle.com>, linux-block@...r.kernel.org, netdev@...r.kernel.org, linux-afs@...ts.infradead.org, alsa-devel@...a-project.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 2/5] rxrpc: Fix uninitialized error code in rxrpc_send_data_packet() Geert Uytterhoeven <geert@...ux-m68k.org> wrote: > While this is not a real false-positive, I believe it cannot cause harm > in practice, as AF_RXRPC cannot be used with other transport families > than IPv4 and IPv6. Agreed. > --- > net/rxrpc/output.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c > index 004c762c2e8d063c..1473d774d67100c5 100644 > --- a/net/rxrpc/output.c > +++ b/net/rxrpc/output.c > @@ -403,8 +403,10 @@ int rxrpc_send_data_packet(struct rxrpc_call *call, struct sk_buff *skb, > > /* send the packet with the don't fragment bit set if we currently > * think it's small enough */ > - if (iov[1].iov_len >= call->peer->maxdata) > + if (iov[1].iov_len >= call->peer->maxdata) { > + ret = 0; > goto send_fragmentable; > + } > > down_read(&conn->params.local->defrag_sem); > Simply setting 0 is wrong. That would give the impression that the thing worked if support for a new transport address family was added and came through this function without full modification (say AF_INET7 becomes a thing). A better way to do things would be to add a default case into the send_fragmentable switch statement that either BUG's or sets -EAFNOSUPPORT. David
Powered by blists - more mailing lists