netdev - Re: UDP sockets oddities

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170825.211724.1703031815383559958.davem@davemloft.net>
Date:   Fri, 25 Aug 2017 21:17:24 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     f.fainelli@...il.com
Cc:     eric.dumazet@...il.com, netdev@...r.kernel.org, pabeni@...hat.com,
        willemb@...gle.com
Subject: Re: UDP sockets oddities

From: Florian Fainelli <f.fainelli@...il.com>
Date: Fri, 25 Aug 2017 20:25:26 -0700

> It would. Since the call trace involves udp_send_skb() how come we are
> not returning an error to write(2)? are there other code paths where the
> neighbor code can do drops like these?

Keep in mind that the neighbour code isn't dropping the current 'skb'
coming from the IP stack, it's dropping the oldest packet in the
resolution queue.