{"id":"CVE-2026-63996","title":"In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: cmis: require exact CDB reply length\n\nMalicious SFP module could respond with rpl_len longer than\nwhat cmis_cdb_process_reply() expected, leading to OOB writes…","summary":"In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: cmis: require exact CDB reply length\n\nMalicious SFP module could respond with rpl_len longer than\nwhat cmis_cdb_process_reply() expected, leading to OOB writes…","severity":"high","cvss":7.8,"cvssVector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","cwe":["CWE-787"],"vendor":"linux","product":"linux_kernel","affected":["linux_kernel >= 6.11, < 6.12.93","linux_kernel >= 6.13, < 6.18.35","linux_kernel >= 6.19, < 7.0.12","linux_kernel = 7.1"],"patched":["linux_kernel 7.0.12"],"published":"2026-07-19","updated":"2026-10-02","sourceUpdated":"2026-10-02T19:58:45.670","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-63996","references":[{"url":"https://git.kernel.org/stable/c/2f818cc98fd2c63a08239cb48995f6c3bfe9d9b3","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/4d42fb88ec61f2e98c33a9e3a2de371d5edbc6b1","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/6c3f999a9d1338c6c89a9ff4549eafe72bc2e7b1","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/eb5dcd740cd7fa27bc2caeff2d28ef28e93ff4d3","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd"],"epss":0.00129,"epssPercentile":0.0213,"ingestedAt":"2026-10-02T22:33:09.809Z","slug":"CVE-2026-63996","body":"## Overview\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nethtool: cmis: require exact CDB reply length\n\nMalicious SFP module could respond with rpl_len longer than\nwhat cmis_cdb_process_reply() expected, leading to OOB writes.\nMalicious HW is a bit theoretical but some modules may just\nbe buggy and/or the reads may occasionally get corrupted,\nso let's protect the kernel.\n\nThe existing check protects from short replies. We need to\nprotect from long ones, too. All callers that pass a non-zero\nrpl_exp_len cast the reply payload to a fixed-layout struct\nand read fields at fixed offsets, with no version negotiation\nor short-reply handling:\n\n  - cmis_cdb_validate_password()\n  - cmis_cdb_module_features_get()\n  - cmis_fw_update_fw_mng_features_get()\n\nso let's assume that responses longer than expected do not\nhave to be handled gracefully here. Add a warning message\nto make the debug easier in case my understanding is wrong...\n\nNote that page_data->length (argument of kmalloc) comes from\nlast arg to ethtool_cmis_page_init() which is rpl_exp_len.\n\nNote2 that AIs also like to point out overflows in args->req.payload\nitself (which is a fixed-size 120 B buffer, on the stack),\nbut callers should be reading structs defined by the standard,\nso protecting from requests for more data than max seem like\ndefensive programming.\n\n## Affected\n\n- `linux_kernel >= 6.11, < 6.12.93`\n- `linux_kernel >= 6.13, < 6.18.35`\n- `linux_kernel >= 6.19, < 7.0.12`\n- `linux_kernel = 7.1`\n\n## Remediation\n\nUpgrade past the affected range:\n\n- `linux_kernel 7.0.12`","depth":"twilight","depthScore":43,"depthScoreParts":{"impact":42.9,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}