> -----Original Message----- > From: Dan Carpenter [mailto:dan.carpenter@xxxxxxxxxx] > Sent: Monday, September 16, 2013 8:06 AM > To: KY Srinivasan > Cc: olaf@xxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; jasowang@xxxxxxxxxx; > dmitry.torokhov@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; vojtech@xxxxxxx; > linux-input@xxxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/1] Drivers: input: serio: New driver to support Hyper-V > synthetic keyboard > > On Mon, Sep 16, 2013 at 02:46:24PM +0000, KY Srinivasan wrote: > > > > + case VM_PKT_DATA_INBAND: > > > > + hv_kbd_on_receive(device, desc); > > > > > > This is the error handling I mentioned at the top. hv_kbd_on_receive() > > > doesn't take into consideration the amount of data we recieved, it > > > trusts the offset we recieved from the user. There is an out of bounds > > > read. > > > > What user are you referring to. The message is sent by the host - the user > keystroke > > is normalized into a fixed size packet by the host and sent to the guest. We will > parse this > > packet, based on the host specified layout here. > > > > The user means the hypervisor, yes. > > I don't want the hypervisor accessing outside of the buffer. It is > robustness issue. Just check the offset against "bytes_recvd". It's > not complicated. At the outset, let me apologize for not understanding your concern. You say: " I don't want the hypervisor accessing outside of the buffer" Where did you see the hypervisor accessing anything outside the buffer? The buffer is allocated by this driver and a packet from vmbus is read into this buffer - this is the call to vmbus_recvpacket(). If the specified buffer is smaller than the packet that needs to be read, then nothing will be read. Once the read completes, we can be sure we have read a valid packet and can proceed to parse it in this driver. I don't want to be argumentative, I am just not seeing the issue. Regards, K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
