netdev - RE: [EXTERNAL] [PATCH net] octeontx2-pf: fix FLOW_DIS_IS

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]

Date: Fri, 12 Apr 2024 05:34:07 +0000
From: Suman Ghosh <sumang@...vell.com>
To: Asbjørn Sloth Tønnesen <ast@...erby.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "David S.
 Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub
 Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Sunil Kovvuri
 Goutham <sgoutham@...vell.com>,
        Geethasowjanya Akula <gakula@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
        Hariprasad Kelam
	<hkelam@...vell.com>
Subject: RE: [EXTERNAL] [PATCH net] octeontx2-pf: fix FLOW_DIS_IS_FRAGMENT
 implementation

>Subject: [EXTERNAL] [PATCH net] octeontx2-pf: fix FLOW_DIS_IS_FRAGMENT
>implementation
>
>Prioritize security for external emails: Confirm sender and content safety
>before clicking links or opening attachments
>
>----------------------------------------------------------------------
>Upon reviewing the flower control flags handling in this driver, I notice
>that the key wasn't being used, only the mask.
>
>Ie. `tc flower ... ip_flags nofrag` was hardware offloaded as `... ip_flags
>frag`.
>
>Only compile tested, no access to HW.
>
>Fixes: c672e3727989 ("octeontx2-pf: Add support to filter packet based on
>IP fragment")
>Signed-off-by: Asbjørn Sloth Tønnesen <ast@...erby.net>
>---
>
>This is a best guess on a fix, I don't know if it will work, but hopefully
>someone at Marvell can test it.
>
>The more certain alternative would be to set an error msg.
>and return -EOPNOTSUPP, when `tc flower ip_flags nofrag` is used.
>
> drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
>b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
>index 87bdb93cb066e..f4655a8c0705d 100644
>--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
>+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_tc.c
>@@ -688,22 +688,25 @@ static int otx2_tc_prepare_flow(struct otx2_nic *nic,
>struct otx2_tc_flow *node,
> 	}
>
> 	if (flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_CONTROL)) {
> 		struct flow_match_control match;
>+		u32 val;
>
> 		flow_rule_match_control(rule, &match);
> 		if (match.mask->flags & FLOW_DIS_FIRST_FRAG) {
> 			NL_SET_ERR_MSG_MOD(extack, "HW doesn't support frag
>first/later");
> 			return -EOPNOTSUPP;
> 		}
>
> 		if (match.mask->flags & FLOW_DIS_IS_FRAGMENT) {
>+			val = match.key->flags & FLOW_DIS_IS_FRAGMENT;
> 			if (ntohs(flow_spec->etype) == ETH_P_IP) {
>-				flow_spec->ip_flag = IPV4_FLAG_MORE;
>+				flow_spec->ip_flag = val ? IPV4_FLAG_MORE : 0;
[Suman] Do we need this? If user provide the command "tc filter add .... ip_flags nofrags" then the above if check should not be hit right? If we are inside the check then we always want to set IPV4_FLAG_MORE right?

> 				flow_mask->ip_flag = IPV4_FLAG_MORE;
> 				req->features |= BIT_ULL(NPC_IPFRAG_IPV4);
> 			} else if (ntohs(flow_spec->etype) == ETH_P_IPV6) {
>-				flow_spec->next_header = IPPROTO_FRAGMENT;
>+				flow_spec->next_header = val ?
>+							 IPPROTO_FRAGMENT : 0;
> 				flow_mask->next_header = 0xff;
> 				req->features |= BIT_ULL(NPC_IPFRAG_IPV6);
> 			} else {
> 				NL_SET_ERR_MSG_MOD(extack, "flow-type should be either
>IPv4 and IPv6");
>--
>2.43.0