On Mon, 27 Jan 2025 at 14:48, Hongren Zheng <i...@zenithal.me> wrote: > > On Mon, Jan 13, 2025 at 05:38:56PM +0800, Hongren Zheng wrote: > > When USBPacket in OUT direction has larger payload > > than the ep_out_buffer (of size 512), a buffer overflow > > would occur. > > > > It could be fixed by limiting the size of usb_packet_copy > > to be at most buffer size. Further optimization gets rid > > of the ep_out_buffer and directly uses ep_out as the target > > buffer. > > > > This is reported by a security researcher who artificially > > constructed an OUT packet of size 2047. The report has gone > > through the QEMU security process, and as this device is for > > testing purpose and no deployment of it in virtualization > > environment is observed, it is triaged not to be a security bug. > > > > Reported-by: Juan Jose Lopez Jaimez <thatjia...@gmail.com> > > Signed-off-by: Hongren Zheng <i...@zenithal.me> > > --- > > hw/usb/canokey.c | 6 +++--- > > hw/usb/canokey.h | 4 ---- > > 2 files changed, 3 insertions(+), 7 deletions(-) > > Seems that the USB subsystem has been orphaned > and there is no maintainer now. > > I used to ask the USB maintainer to pass the patch > because I could not send a PULL, which requires > gpg signature. > > I wonder which maintainer I should ask for now.
I can pick this up; I'm not super familiar with either our USB code or the canokey device, but the change looks OK to me, and I assume you've tested it. Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> and I'll put it into my upcoming target-arm pullreq. thanks -- PMM
