| 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: <20220717141856.GB3118@localhost.localdomain>
Date: Sun, 17 Jul 2022 16:18:56 +0200
From: Guillaume Nault <gnault@...hat.com>
To: Marcin Szycik <marcin.szycik@...ux.intel.com>
Cc: netdev@...r.kernel.org, anthony.l.nguyen@...el.com,
davem@...emloft.net, xiyou.wangcong@...il.com,
jesse.brandeburg@...el.com, gustavoars@...nel.org,
baowen.zheng@...igine.com, boris.sukholitko@...adcom.com,
edumazet@...gle.com, kuba@...nel.org, jhs@...atatu.com,
jiri@...nulli.us, kurt@...utronix.de, pablo@...filter.org,
pabeni@...hat.com, paulb@...dia.com, simon.horman@...igine.com,
komachi.yoshiki@...il.com, zhangkaiheb@....com,
intel-wired-lan@...ts.osuosl.org,
michal.swiatkowski@...ux.intel.com, wojciech.drewek@...el.com,
alexandr.lobakin@...el.com, mostrows@...akeasy.net,
paulus@...ba.org
Subject: Re: [RFC PATCH net-next v5 1/4] flow_dissector: Add PPPoE dissectors
On Fri, Jul 15, 2022 at 03:04:27PM +0200, Marcin Szycik wrote:
> +/**
> + * is_ppp_proto_supported - checks if inner PPP protocol should be dissected
> + * @proto: protocol type (PPP proto field)
> + */
> +static bool is_ppp_proto_supported(__be16 proto)
> +{
> + switch (proto) {
> + case htons(PPP_AT):
> + case htons(PPP_IPX):
> + case htons(PPP_VJC_COMP):
> + case htons(PPP_VJC_UNCOMP):
> + case htons(PPP_MP):
> + case htons(PPP_COMPFRAG):
> + case htons(PPP_COMP):
> + case htons(PPP_IPCP):
> + case htons(PPP_ATCP):
> + case htons(PPP_IPXCP):
> + case htons(PPP_IPV6CP):
> + case htons(PPP_CCPFRAG):
> + case htons(PPP_MPLSCP):
> + case htons(PPP_LCP):
> + case htons(PPP_PAP):
> + case htons(PPP_LQR):
> + case htons(PPP_CHAP):
> + case htons(PPP_CBCP):
> + return true;
> + default:
> + return false;
> + }
> +}
The more I think about it, the more I believe we should make this
function more generic by following the Protocol field definition found
in section 2 of RFC 1661:
https://datatracker.ietf.org/doc/html/rfc1661#section-2
I mean, it's very surprising that is_ppp_proto_supported() returns
false for protocols like PPP_IP or PPP_IPV6, which certainly are
supported. Of course, in the context of your patch, PPP_IP and PPP_IPV6
have been tested first, but that makes the code a bit unclear.
We could define a simpler and more generic helper function (probably in
a ppp header file). Something like (unstested):
/* Assumes proto isn't compressed. */
static bool ppp_proto_is_valid(u16 proto) /*
{
/* Protocol must be odd and the least significant bit of the
* most significant octet must be 0 (see RFC 1661, section 2).
*/
return !!(proto & 0X0101 == 0x0001)
}
BTW, we don't have to restrict the list of supported protocols to the
PPP_* numbers defined in the kernel as we have no indication that the PPP
frame is going to be handled locally.
> +static bool is_pppoe_ses_hdr_valid(struct pppoe_hdr hdr)
> +{
> + return hdr.ver == 1 && hdr.type == 1 && hdr.code == 0;
> +}
> +
> /**
> * __skb_flow_dissect - extract the flow_keys struct and return it
> * @net: associated network namespace, derived from @skb if NULL
> @@ -1214,26 +1250,61 @@ bool __skb_flow_dissect(const struct net *net,
> struct pppoe_hdr hdr;
> __be16 proto;
> } *hdr, _hdr;
> + u16 ppp_proto;
> +
> hdr = __skb_header_pointer(skb, nhoff, sizeof(_hdr), data, hlen, &_hdr);
> if (!hdr) {
> fdret = FLOW_DISSECT_RET_OUT_BAD;
> break;
> }
>
> - nhoff += PPPOE_SES_HLEN;
> - switch (hdr->proto) {
> - case htons(PPP_IP):
> + if (!is_pppoe_ses_hdr_valid(hdr->hdr)) {
> + fdret = FLOW_DISSECT_RET_OUT_BAD;
> + break;
> + }
> +
> + /* least significant bit of the least significant octet
That's the least significant bit of the _most significant_ octet (the
one of the least significant octet must always be 1).
> + * indicates if protocol field was compressed
> + */
> + ppp_proto = ntohs(hdr->proto);
> + if (ppp_proto & 256) {
Using hex would improve readability in my opinion (that is,
s/256/0x0100/).
> + ppp_proto = htons(ppp_proto >> 8);
I don't get why you convert ppp_proto back to network byte order.
That contradicts the type annotation (u16).
> + nhoff += PPPOE_SES_HLEN - 1;
> + } else {
> + ppp_proto = htons(ppp_proto);
Same here. We could leave ppp_proto untouched in this branch.
> + nhoff += PPPOE_SES_HLEN;
> + }
> +
> + if (ppp_proto == htons(PPP_IP)) {
With ppp_proto kept in host byte order, the htons() call would need to
go.
> proto = htons(ETH_P_IP);
> fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
> - break;
> - case htons(PPP_IPV6):
> + } else if (ppp_proto == htons(PPP_IPV6)) {
Same here, and in the following 'if' branches.
> proto = htons(ETH_P_IPV6);
> fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
> - break;
> - default:
> + } else if (ppp_proto == htons(PPP_MPLS_UC)) {
> + proto = htons(ETH_P_MPLS_UC);
> + fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
> + } else if (ppp_proto == htons(PPP_MPLS_MC)) {
> + proto = htons(ETH_P_MPLS_MC);
> + fdret = FLOW_DISSECT_RET_PROTO_AGAIN;
> + } else if (is_ppp_proto_supported(ppp_proto)) {
> + fdret = FLOW_DISSECT_RET_OUT_GOOD;
> + } else {
> fdret = FLOW_DISSECT_RET_OUT_BAD;
> break;
> }
> +
> + if (dissector_uses_key(flow_dissector,
> + FLOW_DISSECTOR_KEY_PPPOE)) {
> + struct flow_dissector_key_pppoe *key_pppoe;
> +
> + key_pppoe = skb_flow_dissector_target(flow_dissector,
> + FLOW_DISSECTOR_KEY_PPPOE,
> + target_container);
> + key_pppoe->session_id = hdr->hdr.sid;
> + key_pppoe->ppp_proto = ppp_proto;
With ppp_proto being u16, we'd now need to call htons(ppp_proto).
> + key_pppoe->type = htons(ETH_P_PPP_SES);
> + }
> break;
> }
> case htons(ETH_P_TIPC): {
> --
> 2.35.1
>
Powered by blists - more mailing lists