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

Why it is Amber

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

References

• https://git.kernel.org/stable/c/05762c5bc1cfdcac36747994fde2c04387a457f1
• https://git.kernel.org/stable/c/491e33144dee872cffda207f6fcb09260728f803
• https://git.kernel.org/stable/c/72eaef1f37a3b6bec11c342736834dc3707be3e4
• https://git.kernel.org/stable/c/858d5ac22cb889266993e7670f9f0c4f4aeedd78
• https://git.kernel.org/stable/c/8749946579708ea0d339034bb7f423a67dbe89cf
• https://git.kernel.org/stable/c/96c436e4b010711452b2872558938f4ef276492a

Original description

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix next_buffer UAF and NextCommand bounds in compound PDUs Fix several related bounds checking and pointer lifecycle issues in receive_encrypted_standard()'s handling of compound encrypted frames: - Clear next_buffer after assigning it to server->bigbuf. A stale next_buffer pointer can lead to a use-after-free on subsequent error paths. - Update pdu_length to the decrypted plaintext size (buf_size). Using the pre-decryption length allows NextCommand to point into stale ciphertext residue. - Reject next_cmd values smaller than MID_HEADER_SIZE(server). - Fix an integer overflow in the upper bound check by verifying pdu_length - next_cmd < MID_HEADER_SIZE(server), ensuring the trailing slice is large enough for a header.