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: <689os02o-r5o8-so9-rq11-p62223p87ns3@vanv.qr> Date: Wed, 12 Apr 2023 18:14:25 +0200 (CEST) From: Jan Engelhardt <jengelh@...i.de> To: Matthieu Baerts <matthieu.baerts@...sares.net> cc: Jakub Kicinski <kuba@...nel.org>, Pablo Neira Ayuso <pablo@...filter.org>, netfilter-devel@...r.kernel.org, davem@...emloft.net, netdev@...r.kernel.org, pabeni@...hat.com, edumazet@...gle.com, mathew.j.martineau@...ux.intel.com, mptcp@...ts.linux.dev Subject: Re: [PATCH net,v2] uapi: linux: restore IPPROTO_MAX to 256 and add IPPROTO_UAPI_MAX On Wednesday 2023-04-12 17:22, Matthieu Baerts wrote: >>> But I don't know how to >>> make sure this will not have any impact on MPTCP on the userspace side, >>> e.g. somewhere before calling the socket syscall, a check could be done >>> to restrict the protocol number to IPPROTO_MAX and then breaking MPTCP >>> support. >> >> Then again any code which stores the ipproto in an unsigned char will >> be broken. A perfect solution is unlikely to exist. IPPROTO_MPTCP (262) is new, anything using MPTCP is practically new code for the purposes of discussion, and when MPTCP support is added to some application, you simply *have to* update any potential uint8 check. >I wonder if the root cause is not the fact we mix the usage of the >protocol parameter from the socket syscall (int/s32) and the protocol >field from the IP header (u8). > >To me, the enum is linked to the socket syscall, not the IP header. In >this case, it would make sense to have a dedicated "MAX" macro for the >IP header, no? IPPROTO_MAX (256) was the sensible maximum value [array size] for both the IP header *and* the socket interface. Then the socket interface was extended, so IPPROTO_MAX, at the very least, keeps the meanings it can keep, which is for the one for the IP header. Makes me wonder why MPTCP got 262 instead of just 257.
Powered by blists - more mailing lists