Live › vulnerability › CVE-2026-99157
Go to dashboardThe Linux SCSI BSG transport allocates a 96-byte reply buffer, but the UFS Advanced RPMB reply can be 104 bytes, so an extra 8 bytes are written past the end of the buffer. The sources do not state what an attacker can achieve beyond the out-of-bounds write.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
Systems running a Linux kernel with UFS storage and the bsg transport using Advanced RPMB commands are the ones the description points at. The sources do not say which kernel versions or hardware are affected, or whether an unprivileged user can trigger the path.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
scsi: bsg: Pass reply_len to bsg_setup_queue() to fit UFS ARPMB replies
bsg-lib allocates a 96-byte (SCSI_SENSE_BUFFERSIZE) reply buffer per job, but struct ufs_rpmb_reply is 104 bytes: a 40-byte struct ufs_bsg_reply followed by a 64-byte EHS. When an Advanced RPMB command returns an EHS, ufshcd_advanced_rpmb_req_handler() copies it right after the 40-byte header and writes 8 bytes past the end of the buffer.
Let each BSG transport pass its reply buffer size to bsg_setup_queue() and have ufs_bsg request sizeof(struct ufs_rpmb_reply), so the full reply reaches user space. Other transports keep SCSI_SENSE_BUFFERSIZE.
This page as .md · .json · in your agent: get_signal("CVE-2026-99157")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.