[PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init

[PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init

[Aleksandr Loktionov]

set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
providing ptype >= 1024 through VIRTCHNL, resulting in a write past
the end of the bitmap and a kernel page fault.

Reproduced with a custom kernel module injecting a crafted
VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592),
FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0,
kernel 7.1.0-rc1.

crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
crash_parser: setting ptype=0xffff (max valid=1023)
crash_parser: calling ice_parser_profile_init -- expect OOB crash!
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1
Hardware name: Intel Corporation S2600BPB/S2600BPB
RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice]
Call Trace:
 <TASK>
 ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
 crash_init+0x127/0xff0 [crash_parser]
 do_one_initcall+0x45/0x310
 do_init_module+0x64/0x270
 init_module_from_file+0xcc/0xf0
 idempotent_init_module+0x17b/0x280
 __x64_sys_finit_module+0x6e/0xe0

Bail out early with -EINVAL when ptype is out of range.

Fixes: e312b3a1e209 ("ice: add API for parser profile initialization")
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c b/drivers/net/ethernet/intel/ice/ice_parser.c
index f8e6963..3ede4c1 100644
--- a/drivers/net/ethernet/intel/ice/ice_parser.c
+++ b/drivers/net/ethernet/intel/ice/ice_parser.c
@@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct ice_parser_result *rslt,
 	u16 proto_off = 0;
 	u16 off;
 
+	if (rslt->ptype >= ICE_FLOW_PTYPE_MAX)
+		return -EINVAL;
+
 	memset(prof, 0, sizeof(*prof));
 	set_bit(rslt->ptype, prof->ptypes);
 	if (blk == ICE_BLK_SW) {
-- 
2.52.0

[PATCH net] ice: validate FDIR action queue index against VF VSI queue count

[Aleksandr Loktionov]

ice_vc_fdir_parse_action() stores the VF-supplied
action->act_conf.queue.index directly into input->q_index for both
VIRTCHNL_ACTION_QUEUE and VIRTCHNL_ACTION_Q_REGION without checking
whether the index is within the bounds of the VF's VSI.  The validated
value is later programmed into the FDIR descriptor's queue index field,
which means a malicious VF can direct matched traffic to a queue index
it does not own, potentially reaching queues belonging to another VF or
the PF.

Add a bounds check against vsi->num_rxq for both action types, matching
the pattern already used elsewhere in the driver.  Also obtain the VF
VSI pointer locally so the check has access to num_rxq; add the
expected NULL guard for robustness.

Fixes: 0ce332fd62f6 ("ice: Add FDIR pattern action parser for VF")
Fixes: 346bf2504397 ("ice: Add new actions support for VF FDIR")
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
 drivers/net/ethernet/intel/ice/virt/fdir.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/virt/fdir.c b/drivers/net/ethernet/intel/ice/virt/fdir.c
index 4f1f344..1bc524f 100644
--- a/drivers/net/ethernet/intel/ice/virt/fdir.c
+++ b/drivers/net/ethernet/intel/ice/virt/fdir.c
@@ -1152,6 +1152,7 @@ ice_vc_fdir_parse_action(struct ice_vf *vf, struct virtchnl_fdir_add *fltr,
 	struct virtchnl_filter_action_set *as = &fltr->rule_cfg.action_set;
 	struct device *dev = ice_pf_to_dev(vf->pf);
 	struct ice_fdir_fltr *input = &conf->input;
+	struct ice_vsi *vsi;
 	u32 dest_num = 0;
 	u32 mark_num = 0;
 	int i;
@@ -1162,6 +1163,10 @@ ice_vc_fdir_parse_action(struct ice_vf *vf, struct virtchnl_fdir_add *fltr,
 		return -EINVAL;
 	}
 
+	vsi = ice_get_vf_vsi(vf);
+	if (!vsi)
+		return -EINVAL;
+
 	for (i = 0; i < as->count; i++) {
 		struct virtchnl_filter_action *action = &as->actions[i];
 
@@ -1176,11 +1181,21 @@ ice_vc_fdir_parse_action(struct ice_vf *vf, struct virtchnl_fdir_add *fltr,
 			break;
 		case VIRTCHNL_ACTION_QUEUE:
 			dest_num++;
+			if (action->act_conf.queue.index >= vsi->num_rxq) {
+				dev_dbg(dev, "Invalid queue index %u for VF %d\n",
+					action->act_conf.queue.index, vf->vf_id);
+				return -EINVAL;
+			}
 			input->dest_ctl = ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QINDEX;
 			input->q_index = action->act_conf.queue.index;
 			break;
 		case VIRTCHNL_ACTION_Q_REGION:
 			dest_num++;
+			if (action->act_conf.queue.index >= vsi->num_rxq) {
+				dev_dbg(dev, "Invalid queue index %u for VF %d\n",
+					action->act_conf.queue.index, vf->vf_id);
+				return -EINVAL;
+			}
 			input->dest_ctl = ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QGROUP;
 			input->q_index = action->act_conf.queue.index;
 			input->q_region = action->act_conf.queue.region;
-- 
2.52.0

Re: [PATCH net] ice: validate FDIR action queue index against VF VSI queue count

[Simon Horman]

From: 'Simon Horman' <horms@kernel.org>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
ice: validate FDIR action queue index against VF VSI queue count

This patch adds a bounds check on the VF-supplied queue index in
ice_vc_fdir_parse_action() against vsi->num_rxq for both
VIRTCHNL_ACTION_QUEUE and VIRTCHNL_ACTION_Q_REGION, so a VF cannot
direct matched FDIR traffic to queues outside its own VSI.

> diff --git a/drivers/net/ethernet/intel/ice/virt/fdir.c b/drivers/net/ethernet/intel/ice/virt/fdir.c
> index 4f1f3442e52c..1bc524f3616c 100644
> --- a/drivers/net/ethernet/intel/ice/virt/fdir.c
> +++ b/drivers/net/ethernet/intel/ice/virt/fdir.c
> @@ -1152,6 +1152,7 @@ ice_vc_fdir_parse_action(struct ice_vf *vf, struct virtchnl_fdir_add *fltr,

[ ... ]

> @@ -1176,11 +1181,21 @@ ice_vc_fdir_parse_action(struct ice_vf *vf, struct virtchnl_fdir_add *fltr,
>  			break;
>  		case VIRTCHNL_ACTION_QUEUE:
>  			dest_num++;
> +			if (action->act_conf.queue.index >= vsi->num_rxq) {
> +				dev_dbg(dev, "Invalid queue index %u for VF %d\n",
> +					action->act_conf.queue.index, vf->vf_id);
> +				return -EINVAL;
> +			}
>  			input->dest_ctl = ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QINDEX;
>  			input->q_index = action->act_conf.queue.index;
>  			break;
>  		case VIRTCHNL_ACTION_Q_REGION:
>  			dest_num++;
> +			if (action->act_conf.queue.index >= vsi->num_rxq) {
> +				dev_dbg(dev, "Invalid queue index %u for VF %d\n",
> +					action->act_conf.queue.index, vf->vf_id);
> +				return -EINVAL;
> +			}
>  			input->dest_ctl = ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QGROUP;
>  			input->q_index = action->act_conf.queue.index;
>  			input->q_region = action->act_conf.queue.region;

[High]
For the VIRTCHNL_ACTION_Q_REGION case, does this check fully close the
steering hole the commit message describes?

The commit message states that the patch validates the action queue
index for both action types, but the Q_REGION action targets a range
of 2^q_region consecutive queues starting at queue.index, and
action->act_conf.queue.region is still copied verbatim into
input->q_region:

	input->q_index = action->act_conf.queue.index;
	input->q_region = action->act_conf.queue.region;

ice_fdir_fltr documents q_region as:

	/* queue region size (=2^q_region) */
	u8 q_region;

and ice_fdir_get_prgm_desc() programs it into the descriptor's TO_Q
field for the QGROUP destination:

	if (input->dest_ctl ==
	    ICE_FLTR_PRGM_DESC_DEST_DIRECT_PKT_QGROUP)
		fdir_fltr_ctx.toq = input->q_region;
	fdir_fltr_ctx.drop = ICE_FXD_FLTR_QW0_DROP_NO;
	fdir_fltr_ctx.qindex = input->q_index;

ICE_FXD_FLTR_QW0_TO_Q_M is a 3-bit field (0x7), so q_region can be up
to 7, i.e. up to 128 queues starting at q_index.

With the new check, a VF can still set queue.index = vsi->num_rxq - 1
(which passes "index >= vsi->num_rxq") together with queue.region up
to 7, causing the hardware to spread matched traffic across queues
beginning at the last valid VF queue and extending past the end of
the VF's VSI into queues owned by another VF or the PF.

Should the Q_REGION case additionally bound queue.region and verify
that queue.index + (1 << queue.region) <= vsi->num_rxq (and possibly
require queue.index to be aligned to 2^queue.region as is conventional
for hardware queue groups)?

Re: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init

[Marcin Szycik]

On 27/05/2026 09:18, Aleksandr Loktionov wrote:
> set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
> ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
> providing ptype >= 1024 through VIRTCHNL, resulting in a write past
> the end of the bitmap and a kernel page fault.
> 
> Reproduced with a custom kernel module injecting a crafted
> VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592),
> FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0,
> kernel 7.1.0-rc1.
> 
> crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
> crash_parser: setting ptype=0xffff (max valid=1023)
> crash_parser: calling ice_parser_profile_init -- expect OOB crash!
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> Oops: Oops: 0002 [#1] SMP NOPTI
> CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1
> Hardware name: Intel Corporation S2600BPB/S2600BPB
> RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice]
> Call Trace:
>  <TASK>
>  ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
>  crash_init+0x127/0xff0 [crash_parser]
>  do_one_initcall+0x45/0x310
>  do_init_module+0x64/0x270
>  init_module_from_file+0xcc/0xf0
>  idempotent_init_module+0x17b/0x280
>  __x64_sys_finit_module+0x6e/0xe0
> 
> Bail out early with -EINVAL when ptype is out of range.
> 
> Fixes: e312b3a1e209 ("ice: add API for parser profile initialization")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com>

> ---
>  drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c b/drivers/net/ethernet/intel/ice/ice_parser.c
> index f8e6963..3ede4c1 100644
> --- a/drivers/net/ethernet/intel/ice/ice_parser.c
> +++ b/drivers/net/ethernet/intel/ice/ice_parser.c
> @@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct ice_parser_result *rslt,
>  	u16 proto_off = 0;
>  	u16 off;
>  
> +	if (rslt->ptype >= ICE_FLOW_PTYPE_MAX)
> +		return -EINVAL;
> +
>  	memset(prof, 0, sizeof(*prof));
>  	set_bit(rslt->ptype, prof->ptypes);
>  	if (blk == ICE_BLK_SW) {

Re: [PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init

[Tony Nguyen]

On 5/27/2026 12:18 AM, Aleksandr Loktionov wrote:
> set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
> ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
> providing ptype >= 1024 through VIRTCHNL, resulting in a write past
> the end of the bitmap and a kernel page fault.
> 
> Reproduced with a custom kernel module injecting a crafted
> VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592),
> FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0,
> kernel 7.1.0-rc1.
> 
> crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
> crash_parser: setting ptype=0xffff (max valid=1023)
> crash_parser: calling ice_parser_profile_init -- expect OOB crash!
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> Oops: Oops: 0002 [#1] SMP NOPTI
> CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1
> Hardware name: Intel Corporation S2600BPB/S2600BPB
> RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice]
> Call Trace:
>   <TASK>
>   ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
>   crash_init+0x127/0xff0 [crash_parser]
>   do_one_initcall+0x45/0x310
>   do_init_module+0x64/0x270
>   init_module_from_file+0xcc/0xf0
>   idempotent_init_module+0x17b/0x280
>   __x64_sys_finit_module+0x6e/0xe0
> 
> Bail out early with -EINVAL when ptype is out of range.
> 
> Fixes: e312b3a1e209 ("ice: add API for parser profile initialization")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
>   drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c b/drivers/net/ethernet/intel/ice/ice_parser.c
> index f8e6963..3ede4c1 100644
> --- a/drivers/net/ethernet/intel/ice/ice_parser.c
> +++ b/drivers/net/ethernet/intel/ice/ice_parser.c
> @@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct ice_parser_result *rslt,
>   	u16 proto_off = 0;
>   	u16 off;
>   
> +	if (rslt->ptype >= ICE_FLOW_PTYPE_MAX)
> +		return -EINVAL;

Patch applied.

Though since you seem to be hardening the drivers, Sashiko reports a lot 
of other issues from this that could be looked into:

This is a pre-existing issue, but does ice_proto_off_resolve() lack a bounds
check for rslt->po_num during protocol resolution?
The parser loops over ICE_PO_PAIR_SIZE - 1 (255) possible protocol IDs and
adds matched protocols to the rslt->po array, incrementing rslt->po_num.
Without a bounds check to ensure rslt->po_num doesn't exceed the capacity of
rslt->po (which is 16), could a malicious VF provide a crafted packet that
matches more than 16 protocols?
Since rslt is allocated on the stack in callers like ice_vc_fdir_parse_raw()
and ice_vc_add_rss_cfg(), could this overflow the stack array and lead to a
panic or potential privilege escalation?
This is a pre-existing issue, but does an unrestricted header offset (ho)
allow out-of-bounds reads from internal parser memory in ice_rt_ho_set()?
In ice_parser_rt_pktbuf_set(), up to ICE_PARSER_MAX_PKT_LEN (504) bytes of
packet data are copied into rt->pkt_buf (sized 536 bytes). However,
rt->pkt_len is assigned the full original packet length, up to
VIRTCHNL_MAX_SIZE_RAW_PACKET (1024).
The parser loops in ice_parser_rt_execute() limit the header offset (ho)
using rt->pkt_len (1024) instead of the buffer size.
When ho exceeds 536, does ice_rt_ho_set() execute:
memcpy(&rt->gpr[ICE_GPR_HV_IDX], &rt->pkt_buf[ho], ICE_GPR_HV_SIZE);
reading 32 bytes out of bounds from rt->pkt_buf and allowing a malicious VF
to force the parser to read its own internal struct fields as packet data?
This is a pre-existing issue, but do dynamic allocations for raw FDIR flow
configurations leak when a flow is deleted or fails?
In ice_vc_fdir_parse_raw(), memory is allocated for conf->prof using
kzalloc_obj() and for conf->pkt_buf using kzalloc(). However, when the 
filter
configuration is later destroyed, such as in the validate_only path of
ice_vc_add_fdir_fltr() or during ice_vc_fdir_flush_entry(), the code only
calls devm_kfree(dev, conf).
Does this free the top-level conf structure but leak the prof and pkt_buf
allocations? Can a malicious VF repeatedly trigger this leak by sending
VIRTCHNL_OP_ADD_FDIR_FILTER with validate_only set to exhaust host memory?
This is a pre-existing issue, but does reading 16-bit values from 
potentially
unaligned byte offsets in the packet buffer cause unaligned memory access
issues?
Further down in ice_parser_profile_init(), the loop increments the byte
offset off by 1 and directly casts the unaligned byte pointers to const 
u16 *
before dereferencing them:
	prof->fv[prof->fv_num].spec = *(const u16 *)&pkt_buf[off];
	prof->fv[prof->fv_num].msk = *(const u16 *)&msk_buf[off];
While this might be tolerated on x86 architectures, will this result in
kernel alignment faults or panics on architectures with strict alignment
requirements? Should this code use the kernel's get_unaligned() macro to
safely extract these values instead?


>   	memset(prof, 0, sizeof(*prof));
>   	set_bit(rslt->ptype, prof->ptypes);
>   	if (blk == ICE_BLK_SW) {

RE: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init

[Romanowski, Rafal]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Tony
> Nguyen
> Sent: Friday, June 5, 2026 10:02 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; intel-wired-
> lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-range ptype in
> ice_parser_profile_init
> 
> 
> 
> On 5/27/2026 12:18 AM, Aleksandr Loktionov wrote:
> > set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
> > ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
> > providing ptype >= 1024 through VIRTCHNL, resulting in a write past
> > the end of the bitmap and a kernel page fault.
> >
> > Reproduced with a custom kernel module injecting a crafted
> > VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91
> 0x800214af
> > 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1.
> >
> > crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
> > crash_parser: setting ptype=0xffff (max valid=1023)
> > crash_parser: calling ice_parser_profile_init -- expect OOB crash!
> > BUG: kernel NULL pointer dereference, address: 0000000000000000
> > #PF: supervisor write access in kernel mode
> > #PF: error_code(0x0002) - not-present page
> > Oops: Oops: 0002 [#1] SMP NOPTI
> > CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U
> > OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB
> > RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace:
> >   <TASK>
> >   ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
> >   crash_init+0x127/0xff0 [crash_parser]
> >   do_one_initcall+0x45/0x310
> >   do_init_module+0x64/0x270
> >   init_module_from_file+0xcc/0xf0
> >   idempotent_init_module+0x17b/0x280
> >   __x64_sys_finit_module+0x6e/0xe0
> >
> > Bail out early with -EINVAL when ptype is out of range.
> >
> > Fixes: e312b3a1e209 ("ice: add API for parser profile initialization")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > ---
> >   drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c
> > b/drivers/net/ethernet/intel/ice/ice_parser.c
> > index f8e6963..3ede4c1 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_parser.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_parser.c
> > @@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct ice_parser_result

Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>

[PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init

[Aleksandr Loktionov]

set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
providing ptype >= 1024 through VIRTCHNL, resulting in a write past
the end of the bitmap and a kernel page fault.

Reproduced with a custom kernel module injecting a crafted
VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592),
FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0,
kernel 7.1.0-rc1.

crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
crash_parser: setting ptype=0xffff (max valid=1023)
crash_parser: calling ice_parser_profile_init -- expect OOB crash!
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
Oops: Oops: 0002 [#1] SMP NOPTI
CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1
Hardware name: Intel Corporation S2600BPB/S2600BPB
RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice]
Call Trace:
 <TASK>
 ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
 crash_init+0x127/0xff0 [crash_parser]
 do_one_initcall+0x45/0x310
 do_init_module+0x64/0x270
 init_module_from_file+0xcc/0xf0
 idempotent_init_module+0x17b/0x280
 __x64_sys_finit_module+0x6e/0xe0

Bail out early with -EINVAL when ptype is out of range.

Fixes: e312b3a1e209 ("ice: add API for parser profile initialization")
Cc: stable@vger.kernel.org
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c b/drivers/net/ethernet/intel/ice/ice_parser.c
index f8e6963..3ede4c1 100644
--- a/drivers/net/ethernet/intel/ice/ice_parser.c
+++ b/drivers/net/ethernet/intel/ice/ice_parser.c
@@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct ice_parser_result *rslt,
 	u16 proto_off = 0;
 	u16 off;
 
+	if (rslt->ptype >= ICE_FLOW_PTYPE_MAX)
+		return -EINVAL;
+
 	memset(prof, 0, sizeof(*prof));
 	set_bit(rslt->ptype, prof->ptypes);
 	if (blk == ICE_BLK_SW) {
-- 
2.52.0