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: [email protected]
Signed-off-by: Aleksandr Loktionov <[email protected]>
---
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) {
