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

[Tony Nguyen <anthony.l.nguyen@intel.com>]

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) {