CVE-2026-63996

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: cmis: require exact CDB reply length<br /> <br /> Malicious SFP module could respond with rpl_len longer than<br /> what cmis_cdb_process_reply() expected, leading to OOB writes.<br /> Malicious HW is a bit theoretical but some modules may just<br /> be buggy and/or the reads may occasionally get corrupted,<br /> so let&amp;#39;s protect the kernel.<br /> <br /> The existing check protects from short replies. We need to<br /> protect from long ones, too. All callers that pass a non-zero<br /> rpl_exp_len cast the reply payload to a fixed-layout struct<br /> and read fields at fixed offsets, with no version negotiation<br /> or short-reply handling:<br /> <br /> - cmis_cdb_validate_password()<br /> - cmis_cdb_module_features_get()<br /> - cmis_fw_update_fw_mng_features_get()<br /> <br /> so let&amp;#39;s assume that responses longer than expected do not<br /> have to be handled gracefully here. Add a warning message<br /> to make the debug easier in case my understanding is wrong...<br /> <br /> Note that page_data-&gt;length (argument of kmalloc) comes from<br /> last arg to ethtool_cmis_page_init() which is rpl_exp_len.<br /> <br /> Note2 that AIs also like to point out overflows in args-&gt;req.payload<br /> itself (which is a fixed-size 120 B buffer, on the stack),<br /> but callers should be reading structs defined by the standard,<br /> so protecting from requests for more data than max seem like<br /> defensive programming.