Question: OCC sensor_length validation in poll response parser

[Runyu Xiao]

Hi,

While doing follow-up review of the OCC hwmon response parser, I noticed
that occ_parse_poll_response() uses the firmware-provided sensor_length to
advance between sensor data blocks, but the later hwmon show callbacks
cast the saved sensor data pointer to fixed C structs such as
struct temp_sensor_10, struct power_sensor_a0, and struct caps_sensor_3.

That raises two questions before I send a patch.

First, should occ_parse_poll_response() check that the next sensor data
block header is still inside the response buffer before reading
block->header?  Today the loop advances to the next block and reads
block->header.num_sensors and block->header.sensor_length before checking
the accumulated size.

Second, is sensor_length expected to match exactly the record size used by
the driver for each known sensor type/version, or can OCC firmware report a
larger record length with reserved or future fields?  The show callbacks
currently index the data as fixed C structs, so a shorter sensor_length
looks unsafe, but I am not sure whether rejecting non-exact lengths would be
too strict for existing firmware.

The local fix I am considering is either:

  1. a narrow bounds fix that only validates the next block header and whole
     block before accepting the block; or

  2. a stricter fix that also rejects known type/version pairs whose
     sensor_length does not match the struct size used by the corresponding
     show callback.

Do you prefer the narrow parser-bounds fix first, or is strict
sensor_length validation also acceptable for OCC responses?

Thanks,
Runyu