On 5/27/2026 12:18 AM, Aleksandr Loktionov wrote:

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