netdev - sock diag uAPI and MPTCP

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 for Android: free password hash cracker in your pocket

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

Message-ID: <c5b53444ca4c79b887629c93d954dadbc4a777da.camel@redhat.com>
Date:   Fri, 19 Jun 2020 12:54:40 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, mptcp@...ts.01.org
Subject: sock diag uAPI and MPTCP

Hi,

IPPROTO_MPTCP value (0x106) can't be represented using the current sock
diag uAPI, as the 'sdiag_protocol' field is 8 bits wide.

To implement diag support for MPTCP socket, we will likely need a
'inet_diag_req_v3' with a wider 'sdiag_protocol'
field. inet_diag_handler_cmd() could detect the version of
the inet_diag_req_v* provided by user-space checking nlmsg_len() and
convert _v2 reqs to _v3.

This change will be a bit invasive, as all in kernel diag users will
then operate only on 'inet_diag_req_v3' (many functions' signature
change required), but the code-related changes will be encapsulated
by inet_diag_handler_cmd().

Would the above be acceptable?

Thanks for any feedback!

Paolo