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  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]
Date:   Sun, 24 Mar 2019 22:38:48 +0100
From:   Kristian Evensen <>
To:     David Miller <>
Cc:     Network Development <>
Subject: Re: [PATCH net-next] fou: Support binding FoU socket


On Thu, Mar 21, 2019 at 9:10 PM David Miller <> wrote:
> This seems to allow adding both a wildcarded and a non-wildcarded fou
> socket, which otherwise has overlapping match scenerios.
> I don't think you want to allow that unless you can determine that
> you aren't creating a situation where multiple fou sockets could
> match the same tunneled packet.

(Apologies to David for multiple copies of this reply. I thought I was
safe from HTML-encoded emails when using Gmail through the browser.
Turns out not to be true for mobile ...)

Thanks for your comments and apoligies for my late reply, Gmail
flagged you message as spam for some reason.

I tried to test and make sure that we would not get any false
positives when mixing non-wildcarded/wildcarded sockets. In my tests,
I first created a wildcard socket bound to port 9999. I then tried to
add a second, non-wildcarded socket bound to the same port. I also
tried to fetch and delete the socket, including souce address, peer
address or interface index in the netlink request. Both the create,
fetch and delete request failed. Deleting/fetching the socket was only
successful when my netlink request attributes matched those used to
create the socket.

I then did the same tests, but with a socket bound to a local ip
address, a socket bound to a local address + interface, and a bound
socket that was also «connected» to a peer. Add only worked when no
socket with the matching source address/interface (or wildcard)
existed, while fetch/delete was only succesful when all attributes

Perhaps there is something I am misunderstanding, or a case I am not aware of?

Thanks again for your comments!


Powered by blists - more mailing lists