In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOB…

Why it is Amber

• CVSS 7.1 high
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/15a221c734b9d044ab769e7e3606b2cab96fb65a
• https://git.kernel.org/stable/c/1cdf0d304d820fb13bf0faf532c3459600f9ea43
• https://git.kernel.org/stable/c/210f0f1f67817e7d2348b86b5115a9b85ef5c98b
• https://git.kernel.org/stable/c/4775c3b7a597907e0b97556c7986fda238a377ae
• https://git.kernel.org/stable/c/74995ee8305a7c4d76ee70d6acd996a75eda3c03
• https://git.kernel.org/stable/c/dbe452a905dfe2804647530a9ff3d7e3826ed04d

Original description

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOB read in smb3_enum_snapshots() If snapshot_array_size is smaller than GMT_TOKEN_SIZE, smb3_enum_snapshots() sets ret_data_len to sizeof(struct smb_snapshot_array) without verifying the actual length of the server's reply. Because SMB2_ioctl() places no lower bound on the server-supplied OutputCount and allocates retbuf to exactly that length, a short reply results in ret_data_len exceeding the size of retbuf. The subsequent copy_to_user() then reads past the end of retbuf, leaking adjacent slab memory to userspace. The subsequent clamp check is ineffective as it only reduces ret_data_len. Fix this by rejecting replies shorter than sizeof(struct smb_snapshot_array) with -EIO. Note that the bound is set to the 12-byte struct size rather than the 16-byte MIN_SNAPSHOT_ARRAY_SIZE defined in MS-SMB2 3.3.5.15.1, because 12 bytes is exactly what copy_to_user() attempts to read.