CVE-2026-31613

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix OOB reads parsing symlink error response<br /> <br /> When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message()<br /> returns success without any length validation, leaving the symlink<br /> parsers as the only defense against an untrusted server.<br /> <br /> symlink_data() walks SMB 3.1.1 error contexts with the loop test "p ErrorId at offset 4 and p-&gt;ErrorDataLength at offset<br /> 0. When the server-controlled ErrorDataLength advances p to within 1-7<br /> bytes of end, the next iteration will read past it. When the matching<br /> context is found, sym-&gt;SymLinkErrorTag is read at offset 4 from<br /> p-&gt;ErrorContextData with no check that the symlink header itself fits.<br /> <br /> smb2_parse_symlink_response() then bounds-checks the substitute name<br /> using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from<br /> iov_base. That value is computed as sizeof(smb2_err_rsp) +<br /> sizeof(smb2_symlink_err_rsp), which is correct only when<br /> ErrorContextCount == 0.<br /> <br /> With at least one error context the symlink data sits 8 bytes deeper,<br /> and each skipped non-matching context shifts it further by 8 +<br /> ALIGN(ErrorDataLength, 8). The check is too short, allowing the<br /> substitute name read to run past iov_len. The out-of-bound heap bytes<br /> are UTF-16-decoded into the symlink target and returned to userspace via<br /> readlink(2).<br /> <br /> Fix this all up by making the loops test require the full context header<br /> to fit, rejecting sym if its header runs past end, and bound the<br /> substitute name against the actual position of sym-&gt;PathBuffer rather<br /> than a fixed offset.<br /> <br /> Because sub_offs and sub_len are 16bits, the pointer math will not<br /> overflow here with the new greater-than.