netdev - Re: Fw: [Bug 214339] New: sendmsg return value may be positive while send errors

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CA+FuTSdH5v3HBUmh-Hvt-4SRgXPVNvdSokq=wids_t2Ze_YBQw@mail.gmail.com>
Date:   Wed, 8 Sep 2021 10:41:29 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org
Subject: Re: Fw: [Bug 214339] New: sendmsg return value may be positive while
 send errors

On Tue, Sep 7, 2021 at 3:11 PM Stephen Hemminger
<stephen@...workplumber.org> wrote:
>
>
>
> Begin forwarded message:
>
> Date: Tue, 07 Sep 2021 09:23:54 +0000
> From: bugzilla-daemon@...zilla.kernel.org
> To: stephen@...workplumber.org
> Subject: [Bug 214339] New: sendmsg return value may be positive while send errors
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=214339
>
>             Bug ID: 214339
>            Summary: sendmsg return value may be positive while send errors
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 4.9.99
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV4
>           Assignee: stephen@...workplumber.org
>           Reporter: 1031265646@...com
>         Regression: No
>
> in file udp.c, a function named udp_sendmsg has a code like this:
>
>         /* Lockless fast path for the non-corking case. */
>         if (!corkreq) {
>                 skb = ip_make_skb(sk, fl4, getfrag, msg, ulen,
>                                   sizeof(struct udphdr), &ipc, &rt,
>                                   msg->msg_flags);
>                 err = PTR_ERR(skb);
>                 if (!IS_ERR_OR_NULL(skb))
>                         err = udp_send_skb(skb, fl4);
>                 goto out;
>         }
>
> but function ip_make_skb may return a null, then err will be set to 0;and out
> like this:

ip_make_skb returns NULL on MSG_PROBE, as intended.

or if __ip_make_skb did not find an skb on __skb_dequeue(queue). But
this is not possible, as __ip_append_data either succeeds and enqueues
an skb or fails and makes ip_send_skb fail before reaching that code.

I don't see anything wrong here.

> out:
>         ip_rt_put(rt);
>         if (free)
>                 kfree(ipc.opt);
>         if (!err)
>                 return len;  // return a positive value
>
> actually, because lock of kernel memory or socket_buffer,

I don't follow this part. This operation runs without locks.

> the ip_make_skb failed
> means the send operation failed. but a positive value is returnd here.
> finnally, users regard the operation was success, but actually it failed in
> kernel.