Re: [Qemu-devel] [PATCH] eepro100: prevent an infinite loop over same command block

Okay, I'll update the patch. @max, @Qinghao: did you have chance to test the current patch? (just checking) Thank you. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH for v2.4.1] exec: fix a glitch in checking dma r/w access

From: Prasad J Pandit While checking r/w access in 'memory_access_is_direct' routine a glitch in the expression leads to segmentation fault while performing dma read operation. Reported-by: Donghai Zdh Signed-off-by: Prasad J Pandit --- exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: [Qemu-devel] [PATCH for v2.4.1] exec: fix a glitch in checking dma r/w access

+-- On Mon, 25 Jan 2016, Paolo Bonzini wrote --+ | > static inline bool memory_access_is_direct(MemoryRegion *mr, bool is_write) | > { | > if (memory_region_is_ram(mr)) { | > -return !(is_write && mr->readonly); | > +return (is_write && !mr->readonly); | | Read or write?

Re: [Qemu-devel] [PATCH for v2.4.1] exec: fix a glitch in checking dma r/w access

Hello Paolo, +-- On Mon, 25 Jan 2016, Paolo Bonzini wrote --+ | This should be handled correctly by address_space_translate_internal: | | if (memory_region_is_ram(mr)) { | diff = int128_sub(section->size, int128_make64(addr)); | *plen = int128_get64(int128_min(diff, int128_m

[Qemu-devel] [PATCH] exec: check 'bounce.in_use' flag before using buffer

From: Prasad J Pandit When IDE AHCI emulation uses Frame Information Structures(FIS) engine for data transfer, the mapped FIS buffer address is stored in a static 'bounce.buffer'. This is freed when FIS entry is unmapped. If multiple FIS entries are created, it leads to an use after free error. C

Re: [Qemu-devel] [PATCH] exec: check 'bounce.in_use' flag before using buffer

Hello Peter, +-- On Thu, 28 Jan 2016, Peter Maydell wrote --+ | This doesn't look right to me. The bounce buffer gets used | if address_space_map() is called on something which isn't | simple guest RAM. In this case address_space_map() will | set bounce.in_use to true and return bounce.buffer a

Re: [Qemu-devel] [PATCH] exec: check 'bounce.in_use' flag before using buffer

+-- On Thu, 28 Jan 2016, Peter Maydell wrote --+ | ahci code should never be passing it to address_space_unmap() | (or indeed doing anything with it at all). Okay. | Instead it needs to handle it as an error case. But it looks like | ahci_cond_start_engines() already does that: | | if

[Qemu-devel] [PATCH v2] ide: ahci: add check before calling dma_memory_unmap

From: Prasad J Pandit When IDE AHCI emulation uses Frame Information Structures(FIS) engine for data transfer, the mapped FIS buffer address is stored in a static 'bounce.buffer'. When a request is made to map another memory region, address_space_map() returns NULL because 'bounce.buffer' is in_u

Re: [Qemu-devel] [PATCH] exec: check 'bounce.in_use' flag before using buffer

+-- On Fri, 29 Jan 2016, P J P wrote --+ | Okay, I'll send a revised patch. I've sent it. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH] usb: ehci: add capability mmio write function

From: Prasad J Pandit USB Ehci emulation supports host controller capability registers. But its mmio '.write' function was missing, which lead to a null pointer dereference issue. Add a do nothing 'ehci_caps_write' definition to avoid it; Do nothing because capability registers are Read Only(RO).

Re: [Qemu-devel] [PATCH] usb: ehci: add capability mmio write function

Hello Gerd, +-- On Fri, 29 Jan 2016, Gerd Hoffmann wrote --+ | On Fr, 2016-01-29 at 18:30 +0530, P J P wrote: | > pointer dereference issue. Add a do nothing 'ehci_caps_write' | > definition to avoid it; Do nothing because capability registers | > are Read Only(RO). | |

Re: [Qemu-devel] [PATCH 1/1] redirect: change the state after attach usb 3.0 devices to xhci

t;speed == USB_SPEED_SUPER && (udev->port->speedmask & USB_SPEED_MASK_SUPER)) { | +udev->state = USB_STATE_DEFAULT; Why conditionally set it to default? -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH] net: ne2000: check ring buffer control registers

From: Prasad J Pandit Ne2000 NIC uses ring buffer of NE2000_MEM_SIZE(49152) bytes to process network packets. Four registers PSTART, PSTOP, CURPAGE and BOUNDARY are used to control ring buffer access. Setting these registers to invalid values could lead to infinite loop or OOB r/w access issues.

Re: [Qemu-devel] [PATCH] eepro100: prevent an infinite loop over same command block

Hello Qinghao, +-- On Fri, 20 Nov 2015, Qinghao Tang wrote --+ | Currently what problem do you have? Perhaps I could provide more support. Could you please confirm if the proposed patch here fixes the issue. Secondly there is uncertainty if the CB loop like Jason mentioned earlier is possi

Re: [Qemu-devel] [PATCH] eepro100: prevent an infinite loop over same command block

Hello Qinghao, +-- On Fri, 20 Nov 2015, Qinghao Tang wrote --+ | I think the patch can solve this vulnerability. | I confirm that the loop exist , the poc code can prove that. Great! Thank you so much for the confirmation and the POC code. I'll send an updated patch shortly. Thank you. -- P

Re: [Qemu-devel] [PATCH for-2.5] eepro100: Prevent two endless loops

command list? Earilier Jason mentioned 256. Not sure what is an ideal count. Thank you. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH for-2.5] eepro100: Prevent two endless loops

I guess Jason would be best to decide that. Thank you. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH] usb: check RNDIS buffer offsets & length

From: Prasad J Pandit When processing remote NDIS control message packets, the USB Net device emulator uses a fixed length(4096) data buffer. The incoming informationBufferOffset & Length combination could cross that range. Check control message buffer offsets and length to avoid it. Reported-by

Re: [Qemu-devel] [PATCH] net: ne2000: check ring buffer control registers

o fiddle with the ring buffers location inside contorller's memory. It does not seem right. | I'm thinking maybe we need check during receiving like what we did in | dd793a74882477ca38d49e191110c17dfee51dcc? Check if (s->start == s->stop) at each receive call? -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] 答复: [PATCH] net: ne2000: check ring buffer control registers

) That'd break the loop, instead of resetting index to s->start, when index reaches s->stop. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH] usb: check RNDIS buffer offsets & length

+-- On Fri, 5 Feb 2016, P J P wrote --+ | From: Prasad J Pandit | | When processing remote NDIS control message packets, the USB Net | device emulator uses a fixed length(4096) data buffer. The incoming | informationBufferOffset & Length combination could cross that range. | Check con

Re: [Qemu-devel] [PATCH 0/4] ahci: unmap fixes

>> ahci: handle LIST_ON and FIS_ON in map helpers >> ahci: explicitly reject bad engine states on post_load >> ahci: prohibit "restarting" the FIS or CLB engines Yes, they look good. Thank you. --- -P J P http://feedmug.com

[Qemu-devel] [PATCH] usb: check USB configuration descriptor object

From: Prasad J Pandit When processing remote NDIS control message packets, the USB Net device emulator checks to see if the USB configuration descriptor object is of RNDIS type(2). But it does not check if it is null, which leads to a null dereference error. Add check to avoid it. Reported-by: Q

Re: [Qemu-devel] [PATCH] net: ne2000: check ring buffer control registers

+-- On Tue, 9 Feb 2016, P J P wrote --+ | +-- On Fri, 5 Feb 2016, Jason Wang wrote --+ | | I suspect this could even work. Consider after realizing, s->stop is | | zero, any attempt to set STARTPG will fail? | | Ie after 'pci_ne2000_realize'? It does not seem to set or reset s->

Re: [Qemu-devel] [PATCH] usb: check RNDIS buffer offsets & length

+-- On Tue, 9 Feb 2016, P J P wrote --+ | +-- On Fri, 5 Feb 2016, P J P wrote --+ | | From: Prasad J Pandit | | | | When processing remote NDIS control message packets, the USB Net | | device emulator uses a fixed length(4096) data buffer. The incoming | | informationBufferOffset & Le

[Qemu-devel] [PATCH] usb: ohci avoid multiple eof timers

From: Prasad J Pandit When transitioning an OHCI controller to the OHCI_USB_OPERATIONAL state, it creates an eof timer object in 'ohci_bus_start'. It does not check if one already exists. This results in memory leakage and null dereference issue. Add a check to avoid it. Reported-by: Zuozhi Fzz

Re: [Qemu-devel] [PATCH] usb: ohci avoid multiple eof timers

Hello Gerd, +-- On Tue, 16 Feb 2016, Gerd Hoffmann wrote --+ | Can you try the attached patch instead? Yes, this one works too. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH 1/2] usb: check RNDIS message length

From: Prasad J Pandit When processing remote NDIS control message packets, the USB Net device emulator uses a fixed length(4096) data buffer. The incoming packet length could exceed this limit. Add a check to avoid it. Signed-off-by: Prasad J Pandit --- hw/usb/core.c | 18 +- 1

[Qemu-devel] [PATCH 2/2] usb: check RNDIS buffer offsets & length

From: Prasad J Pandit When processing remote NDIS control message packets, the USB Net device emulator uses a fixed length(4096) data buffer. The incoming informationBufferOffset & Length combination could overflow and cross that range. Check control message buffer offsets and length to avoid it.

[Qemu-devel] [PATCH 0/2] usb: check RNDIS offsets & length

From: Prasad J Pandit Hello, When processing remote NDIS control message packets, the USB Net device emulator uses a fixed length(4096) data buffer. The incoming packet length could exceed that OR informationBufferOffset & Length combination could overflow and cross that range. These two patches

Re: [Qemu-devel] [PATCH] usb: check RNDIS buffer offsets & length

Hello Gerd, +-- On Tue, 16 Feb 2016, Gerd Hoffmann wrote --+ | Moves up the check so it is done for every control xfer. Good. ... | Why this is needed? All control transfers go through do_token_setup | first, so with the check moved in do_token_setup we should never ever | trigger it here ..

Re: [Qemu-devel] [PATCH] usb: check RNDIS buffer offsets & length

+-- On Tue, 16 Feb 2016, Gerd Hoffmann wrote --+ | > @@ -172,11 +172,18 @@ static void do_token_in(USBDevice *s, USBPacket *p) | > assert(p->ep->nr == 0); | > +if (s->setup_len > sizeof(s->data_buf)) { | > +fprintf(stderr, | > +"usb_generic_handle_packet: ctrl buffe

[Qemu-devel] [PATCH] net: check packet payload length

From: Prasad J Pandit While computing IP checksum, 'net_checksum_calculate' reads payload length from the packet. It could exceed the given 'data' buffer size. Add a check to avoid it. Reported-by: Liu Ling Signed-off-by: Prasad J Pandit --- net/checksum.c | 5 +++-- 1 file changed, 3 inserti

[Qemu-devel] [PATCH] net: minor indentation updates

From: Prasad J Pandit Due indentation and braces were missing at places, added them. Signed-off-by: Prasad J Pandit --- net/checksum.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/net/checksum.c b/net/checksum.c index e51698c..a8c47e3 100644 --- a/n

Re: [Qemu-devel] [PATCH] net: check packet payload length

+-- On Wed, 17 Feb 2016, Markus Armbruster wrote --+ | Is calling this function with a partial IPv4 TCP/UDP packet legitimate? | If partial packet is okay, what about a partial header? Partial? That shouldn't harm I guess. | If not, should we assert plen + hlen <= length? Or == length, even?

Re: [Qemu-devel] [PATCH] net: minor indentation updates

+-- On Wed, 17 Feb 2016, Eric Blake wrote --+ | Cleaning up existing code is best done as part of a series that is | otherwise touching the code; doing it in isolation makes 'git blame' | attribute the wrong author for no good reason. Ah, okay. I noticed it while patching 'net_checksum_calculate

Re: [Qemu-devel] [PATCH] net: check packet payload length

+-- On Thu, 18 Feb 2016, P J P wrote --+ | +-- On Wed, 17 Feb 2016, Markus Armbruster wrote --+ | | Is calling this function with a partial IPv4 TCP/UDP packet legitimate? | | If partial packet is okay, what about a partial header? | | Partial? That shouldn't harm I guess. For partia

[Qemu-devel] net: vmxnet3: memory leakage issue

Hello Dmitry, all A memory leakage issue was reported by Mr Qinghao Tang, CC'd here. In that, the Qemu VMXNET3 paravirtual device emulator does not check if the device is already active, before activating it. This leads to host memory leakage via calls to vmxnet_tx_pkt_init(), which calls g_

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Dmitry, +-- On Thu, 3 Dec 2015, Dmitry Fleytman wrote --+ | The patch is good. | Jason, would you apply is from attachment or should it be resent by "git send-email”? | | Acked-by: Dmitry Fleytman mailto:dmi...@daynix.com>> Thank you. (/me makes a note to learn about git send-email.) --

[Qemu-devel] [PATCH] ui: vnc: avoid floating point exception

Hello Gerd, A floating point exception issue in the VNC server PNG compression support was reported by Mr Lian Yihan, CC'd here. Given below is a proposed (tested)patch to fix this issue. === From 1ca4818333d39fed6567e316e37f6a6516f59c69 Mon Sep 17 00:00:00 2001 From: Prasad J Pandit Dat

Re: [Qemu-devel] [PATCH] ui: vnc: avoid floating point exception

Hello Peter, +-- On Thu, 3 Dec 2015, Peter Maydell wrote --+ | The patch doesn't apply to master. Can you produce a version | that does, please? Please see this new one, hope it works. === >From d4661b8d99f8c8439167d85165439c619553b933 Mon Sep 17 00:00:00 2001 From: Prasad J Pandit Date: Thu,

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Jason, +-- On Fri, 4 Dec 2015, Jason Wang wrote --+ | Better with "git send-email". Okay. | What if guest deactivate the device before re-activate the device? |Looks like it could be done through methods: | |1) VMXNET3_CMD_QUIESCE_DEV IIUC, it is used to pause the device when the re

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Jason, Dmitry, +-- On Tue, 8 Dec 2015, P J P wrote --+ | |1) VMXNET3_CMD_QUIESCE_DEV | | IIUC, it is used to pause the device when the receiver end is unable to | keee-up with the incoming flow. After a brief period, the operation could be | resumed again. | | |2) VMXNET3_REG_DSAL

[Qemu-devel] [PATCH] usb: hcd-ehci: add check to avoid an infinite loop

Hello Gerd, An infinite loop issue was reported by Mr Qinghao Tang(CC'd), in the USB EHCI emulator. In that, a malicious isochronous transfer descriptor(iTD) list could unfold an infinite loop in the 'ehci_advance_state' routine, by always setting 'again = 0 or 1'. Please see below a propo

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Jason, +-- On Fri, 11 Dec 2015, Jason Wang wrote --+ | I think it's possible for attacker. Better wait for Dmitry's answer for | this. Okay. | > +/* Verify if device is active */ | > +if (s->device_active) { | > +VMW_CFPRN("Vmxnet3 device is active"); | > +retu

Re: [Qemu-devel] [PATCH] usb: hcd-ehci: add check to avoid an infinite loop

Hello Gerd, +-- On Mon, 14 Dec 2015, Gerd Hoffmann wrote --+ | Can you test the attached patch please? In case it doesn't fix the bug: Yes, it did fix the infinite loop issue. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH] usb: hcd-ehci: add check to avoid an infinite loop

+-- On Mon, 14 Dec 2015, Gerd Hoffmann wrote --+ | Good. Is there a cve number for that one which I can add to the commit | message? No, not yet. I'll request one, once it is approved for the upstream. Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Dmitry, Jason +-- On Sun, 13 Dec 2015, Dmitry Fleytman wrote --+ | According to Linux driver code VMXNET3_CMD_QUIESCE_DEV does not flip | paused/active states. It always disables device, see vmxnet3_resume() for | |

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Dmitry, +-- On Mon, 14 Dec 2015, Dmitry Fleytman wrote --+ | The patch looks basically good. | The only issue I can think of is that now vmxnet_tx_pkt_uninit and | vmxnet_rx_pkt_uninit may be called a few times in a row. For example guest | may quiesce device and then shutdown. In this

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

+-- On Tue, 15 Dec 2015, Dmitry Fleytman wrote --+ | Hello Prasad, | | Looks good. | Reviewed-by: Dmitry Fleytman Great! Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Jason, +-- On Tue, 15 Dec 2015, Jason Wang wrote --+ | Patch looks good to me. Queued for 2.6 first. | | If you want to make this for 2.5, you may probably want to send a formal | patch with my "Reviewed-by: " to Peter directly consider we are near to | release. And use "For 2.5" as a pre

Re: [Qemu-devel] net: vmxnet3: memory leakage issue

Hello Miao, +-- On Tue, 15 Dec 2015, Miao Yan wrote --+ | So far as I know, vmxnet3 doesn't have a flow control spec. Same is true for | e1000 emulation layer in esxi, writing to flow control register bits is | ignored. Maybe there are some buffering or throttling layer in-between that | do n

[Qemu-devel] [PATCH For 2.5] net: vmxnet3: avoid memory leakage in activate_device

Hello Peter, Patch below is reviewed and queued currently for 2.6. Could you please include it in 2.5? -> https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg02352.html === From 1a18f291a5d22c0dfa680cf82ada2e021e19bf97 Mon Sep 17 00:00:00 2001 From: Prasad J Pandit Date: Tue, 15 D

Re: [Qemu-devel] [PATCH For 2.5] net: vmxnet3: avoid memory leakage in activate_device

+-- On Tue, 15 Dec 2015, Peter Maydell wrote --+ | > -> https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg02352.html | | No, sorry. It is too late by a long way. It can be cc'd to | qemu-stable and go into 2.5.1. I see, okay. I'll send it there. Thank you. -- Prasad J Pandit / Red Hat Pr

Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

+-- On Fri, 8 Jan 2016, Wolfgang Bumiller wrote --+ | On Fri, Jan 08, 2016 at 07:29:31PM +0530, P J P wrote: | > + if (!strncmp(keyname_buf, "<-", 2)) | > and remove the 'keyname_len' altogether. | | This wouldn't catch '<' without '-'.

Re: [Qemu-devel] [PATCH] ide: ahci: reset ncq object to unused on error

+-- On Fri, 8 Jan 2016, John Snow wrote --+ | In both of these error pathways, AIOCB is actually never assigned to | begin with. True, it's mentioned in the commit message. | So it's not necessarily a use-after-free. Yes, right. | I think it should be safe to put ncq_tfs->used = 0 directl

[Qemu-devel] [PATCH v2] ide: ahci: reset ncq object to unused on error

From: Prasad J Pandit When processing NCQ commands, ACHI device emulation prepares a NCQ transfer object; To which an aio control block(aiocb) object is assigned in 'execute_ncq_command'. In case, when the NCQ command is invalid, the 'aiocb' object is not assigned, and NCQ transfer object is left

Re: [Qemu-devel] [PATCH v2] ide: ahci: reset ncq object to unused on error

+-- On Fri, 8 Jan 2016, John Snow wrote --+ | > ide_state->status = READY_STAT | ERR_STAT; | > ncq_tfs->drive->port_regs.scr_err |= (1 << ncq_tfs->tag); | > +ncq_tfs->used = 0; | > } | | Thanks, applied to my IDE tree: | | https://github.com/jnsnow/qemu/commits/ide | https://github

Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

+-- On Sat, 9 Jan 2016, Wolfgang Bumiller wrote --+ | > could say: if (!strcmp(keyname_buf, "<")). | | keyname_len+1 (size instead of length) to include the \0, then yes I think | strcmp can be used this way. The +1 should be fine there (since >= covers | it). Yes, right. --

Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

Hello, +-- On Sun, 10 Jan 2016, Michael Tokarev wrote --+ | So, what's the status of this issue now? | (it is CVE-2015-8619 btw, maybe worth to mention this in the commit message) Yes, if the patch is not yet merged upstream, it'd be good to include this CVE in the commit message. -- Prasad

Re: [Qemu-devel] [PATCH v2 for v2.3.0] fw_cfg: add check to validate current entry value

Hello, +-- On Wed, 6 Jan 2016, P J P wrote --+ | When processing firmware configurations, an OOB r/w access occurs | if 's->cur_entry' is set to be invalid(FW_CFG_INVALID=0x). | Add a check to validate 's->cur_entry' to avoid such access. | | Reported-by: Do

Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

+-- On Mon, 11 Jan 2016, Wolfgang Bumiller wrote --+ | Seems we concluded it's best to keep keyname_len around and simply check it | against the sizeof(keyname_buf). | | Here's a full new version as I haven't seen one yet. (With an adapted commit | message and the CVE id added.) Sorry, i thou

Re: [Qemu-devel] [PATCH v2 for v2.3.0] fw_cfg: add check to validate current entry value

+-- On Mon, 11 Jan 2016, Paolo Bonzini wrote --+ | > +-- On Wed, 6 Jan 2016, P J P wrote --+ | > -> https://patchwork.ozlabs.org/patch/563706/ | > Ping...! Does it look okay? (just checking) | | Yes, it looks good. Okay, thank you. -- Prasad J Pandit / Red Hat Product Security Te

Re: [Qemu-devel] [Qemu-block] [PATCH v2] ide: ahci: reset ncq object to unused on error

+-- On Mon, 11 Jan 2016, John Snow wrote --+ | On 01/11/2016 10:00 AM, Kevin Wolf wrote: | >> When processing NCQ commands, ACHI device emulation prepares a | > | > s/ACHI/AHCI/ Ah, sorry.:( | > Can you still fix this in your tree, John? | Yes, thanks. Thank you. -- Prasad J Pandit / Red Hat

Re: [Qemu-devel] [PATCH] cadence_gem: fix buffer overflow

t_length(desc), | + sizeof(tx_packet) - (p - tx_packet)); | +break; | +} | + Commit message says gem_receive, but the patch fixes gem_transmit() routine. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH] cadence_gem: fix buffer overflow

+-- On Fri, 15 Jan 2016, Jason Wang wrote --+ | Looks like we need similar issue in gen_receive(), need to fix that? Yes, I'm preparing a patch. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH] net: cadence_gem: check packet size in gem_recieve

From: Prasad J Pandit While receiving packets in 'gem_receive' routine, if Frame Check Sequence(FCS) is enabled, it copies the packet into a local buffer without checking its size. Add check to validate packet length against the buffer size to avoid buffer overflow. Reported-by: Ling Liu Signed

Re: [Qemu-devel] [Qemu-arm] [PATCH] cadence_gem: fix buffer overflow

for memory. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PULL 03/15] i386: avoid null pointer dereference

+-- On Fri, 15 Jan 2016, Paolo Bonzini wrote --+ | This is probably due to the original patch being formatted badly, and Sorry! Should I resend it? -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [Qemu-arm] [PATCH] cadence_gem: fix buffer overflow

+-- On Fri, 15 Jan 2016, Alistair Francis wrote --+ | Won't the allocation/reallocation happen on the host? Ah yes, don't know what I was thinking. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH] net: cadence_gem: check packet size in gem_recieve

size <= 2048? | If not, need fix. Sorry? The above check would fix that, no? -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH] usb: check page select value while processing iTD

From: Prasad J Pandit While processing isochronous transfer descriptors(iTD), the page select(PG) field value could lead to an OOB read access. Add check to avoid it. Reported-by: Qinghao Tang Signed-off-by: Prasad J Pandit --- hw/usb/hcd-ehci.c | 10 ++ 1 file changed, 6 insertions(+

[Qemu-devel] [PATCH] sd: limit sd_cmd_type array index 'req.cmd'

From: Prasad J Pandit While processing standard SD commands, the 'req.cmd' value could lead to OOB read when used as an index into 'sd_cmd_type' array. Limit 'req.cmd' value to avoid such an access. Reported-by: Qinghao Tang Signed-off-by: Prasad J Pandit --- hw/sd/sd.c | 4 +++- 1 file chang

[Qemu-devel] [PATCH v2] sd: limit 'req.cmd' while using as an array index

From: Prasad J Pandit While processing standard SD commands, the 'req.cmd' value could lead to OOB read when used as an index into 'sd_cmd_type' or 'sd_cmd_class' arrays. Limit 'req.cmd' value to avoid such an access. Reported-by: Qinghao Tang Signed-off-by: Prasad J Pandit --- hw/sd/sd.c | 7

Re: [Qemu-devel] [PATCH] sd: limit sd_cmd_type array index 'req.cmd'

looked for 'req.cmd', but missed 'req->cmd'. I've sent a revised patch v2. Thank you. -- - P J P 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [RFC PATCH] vfio: Add sysfsdev property for pci & platform

+-- On Wed, 20 Jan 2016, Alex Williamson wrote --+ | > > +error_printf("Warning : Device at %s is known to cause | > > system instability issues during option rom execution. Proceeding | > > anyway since user specified romfile\n", | > > + vdev->vbasedev.name); |

[Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

Hello, An OOB write issue was reported by Mr Ling Liu, CC'd here. It occurs while processing the 'sendkey' command, if the command argument was longer than the 'keyname_buf[16]' buffer. === From b0363f4c0e91671064dd7ffece8a6923c8dcaf20 Mon Sep 17 00:00:00 2001 From: Prasad J Pandit Date:

Re: [Qemu-devel] [PATCH] hmp: avoid redundant null termination of buffer

Hello Ling, +-- On Fri, 18 Dec 2015, 刘令 wrote --+ | Can you give this a cve id? Yes, I'll request one once it is accepted upstream. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

[Qemu-devel] [PATCH] i386: avoid null pointer dereference

Hello, A null pointer dereference issue was reported by Mr Ling Liu, CC'd here. It occurs while doing I/O port write operations via hmp interface. In that, 'current_cpu' remains null as it is not called from cpu_exec loop, which results in the said issue. Below is a proposed (tested)patch

[Qemu-devel] [PATCH] scsi: initialise info object with appropriate size

Hello, A stack overflow issue was reported by Mr Qinghao Tang, CC'd here. It occurs while processing the SCSI controller's CTRL_GET_INFO command, as the memset(2) call uses driver supplied 'cmd->iov_size' to initialise the '&info' object. Please see below a proposed patch to fix this issue.

Re: [Qemu-devel] [PATCH] scsi: initialise info object with appropriate size

+-- On Mon, 21 Dec 2015, Paolo Bonzini wrote --+ | > diff --git a/hw/scsi/megasas.c b/hw/scsi/megasas.c | > index d7dc667..576f56c 100644 | > --- a/hw/scsi/megasas.c | > +++ b/hw/scsi/megasas.c | > @@ -718,7 +718,7 @@ static int megasas_ctrl_get_info(MegasasState *s, | > MegasasCmd *cmd) | > B

Re: [Qemu-devel] [PATCH] qmp: return err msg when powerdown a vm when it isn't in running state

+-- On Mon, 21 Dec 2015, Qinghua Jin wrote --+ | -void qmp_system_powerdown(Error **erp) | +void qmp_system_powerdown(Error **errp) | { | +if (!runstate_is_running()) { | +error_setg(errp, "Can't powerdown the Virtual Machine when it isn't running"); | +return; | +} |

Re: [Qemu-devel] [PATCH] scsi: initialise info object with appropriate size

+-- On Mon, 21 Dec 2015, Paolo Bonzini wrote --+ | I can add the Cc to the commit message as well. For now it's enough to | send a message in Cc so that the qemu-stable people notice it. Okay, great! Thank you. -- Prasad J Pandit / Red Hat Product Security Team 47AF CE69 3A90 54AA 9045 1053 DD13

Re: [Qemu-devel] [PATCH 1/3] net/vmxnet3: return 1 on device activation failure

+-- On Mon, 21 Dec 2015, Miao Yan wrote --+ | So return 1 on device activation failure instead of -1; | | Signed-off-by: Miao Yan | --- | hw/net/vmxnet3.c | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | | diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c | index e168285..9185408 100644

Re: [Qemu-devel] [PATCH] ivshmem: remove redundant assignment, fix crash with msi=off

+-- On Mon, 21 Dec 2015, marcandre.lur...@redhat.com wrote --+ | diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c | index 7d14222..dcfc8cc 100644 | --- a/hw/misc/ivshmem.c | +++ b/hw/misc/ivshmem.c | @@ -355,12 +355,9 @@ static CharDriverState* create_eventfd_chr_device(IVShmemState *s, |

Re: [Qemu-devel] [PATCH v3] qmp: return err msg when powerdown a vm when it isn't in running state

+-- On Tue, 22 Dec 2015, Qinghua Jin wrote --+ | -void qmp_system_powerdown(Error **erp) | +void qmp_system_powerdown(Error **errp) | { | +if (!runstate_check(RUN_STATE_RUNNING)) { | +error_setg(errp, | + "Can not powerdown virtual machine as it is not running"); | +

Re: [Qemu-devel] [PATCH 1/3] net/vmxnet3: return 1 on device activation failure

+-- On Tue, 22 Dec 2015, Miao Yan wrote --+ | > If '1' indicates the error, the 'default:' case in the same switch needs to be | > updated too. | | '1' indicates an error on device activation. Not sure about the 'unknown | command' case. Ideally it should be same, inconsistent return codes wo

[Qemu-devel] [PATCH] net: rocker: fix an incorrect array bounds check

Hello Scott, Jiri A stack overflow issue was reported by Mr Qinghao Tang, CC'd here. It occurs while processing transmit(tx) descriptors in tx_consume() routine. If a descriptor was to have more than allowed(ROCKER_TX_FRAGS_MAX=16) packet fragments, the processing loop suffers an off-by-one

Re: [Qemu-devel] [PATCH] net: rocker: fix an incorrect array bounds check

+-- On Tue, 22 Dec 2015, Jiri Pirko wrote --+ | >From f3461d8098a0572786f5a2d7a492863090c73134 Mon Sep 17 00:00:00 2001 | >From: Prasad J Pandit | >Date: Tue, 22 Dec 2015 18:21:00 +0530 | >Subject: [PATCH] net: rocker: fix an incorrect array bounds check | > | >While processing transmit(tx) descri

Re: [Qemu-devel] [PATCH] net: rocker: fix an incorrect array bounds check

+-- On Tue, 22 Dec 2015, Paolo Bonzini wrote --+ | > -if (++iovcnt > ROCKER_TX_FRAGS_MAX) { | > +if (++iovcnt >= ROCKER_TX_FRAGS_MAX) { | | Doesn't this forbid some valid ROCKER_TX_FRAGS_MAX-element iovecs? forbid..? Sorry, I did not get the question. | The check should be mov

Re: [Qemu-devel] [PATCH] net: rocker: fix an incorrect array bounds check

+-- On Tue, 22 Dec 2015, Paolo Bonzini wrote --+ | > === | > diff --git a/hw/net/rocker/rocker.c b/hw/net/rocker/rocker.c | > index c57f1a6..2e77e50 100644 | > --- a/hw/net/rocker/rocker.c | > +++ b/hw/net/rocker/rocker.c | > @@ -232,6 +232,9 @@ static int tx_consume(Rocker *r, DescInfo *info) | >

[Qemu-devel] [PATCH v2] net: rocker: fix an incorrect array bounds check

Hello Paolo, all Please see an updated patch below, as per suggestion in -> https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg04057.html === From 344a487d637be20b3fb110bec36cb703e7f6ecaa Mon Sep 17 00:00:00 2001 From: Prasad J Pandit Date: Wed, 23 Dec 2015 00:40:13 +0530 Subject: [

Re: [Qemu-devel] [PATCH v2] net: rocker: fix an incorrect array bounds check

+-- On Tue, 22 Dec 2015, Peter Maydell wrote --+ | Could you submit patches in the usual git send-email format, | please? It's easier for maintainers to process them if they're | not in an odd arrangement that requires manual intervention. | (In particular, comments that aren't intended to go in th

[Qemu-devel] [PATCH v2] net: rocker: fix an incorrect array bounds check

From: Prasad J Pandit While processing transmit(tx) descriptors in 'tx_consume' routine the switch emulator suffers from an off-by-one error, if a descriptor was to have more than allowed(ROCKER_TX_FRAGS_MAX=16) fragments. Fix an incorrect bounds check to avoid it. Reported-by: Qinghao Tang Sig

Re: [Qemu-devel] [PATCH v2] net: rocker: fix an incorrect array bounds check

Hello Jason, all +-- On Mon, 28 Dec 2015, Jason Wang wrote --+ | On 12/23/2015 01:14 PM, P J P wrote: | > +-- On Tue, 22 Dec 2015, Peter Maydell wrote --+ | > | Could you submit patches in the usual git send-email format, | > | please? | > | > Yes, surely will do. I did rea

[Qemu-devel] [PATCH] net: ne2000: fix bounds check in ioport operations

From: Prasad J Pandit While doing ioport r/w oprations, ne2000 device emulation suffers from OOB r/w error. Update respective array bounds check to avoid OOB access. Reported-by: Ling Liu Signed-off-by: Prasad J Pandit --- hw/net/ne2000.c | 34 -- 1 file change

[Qemu-devel] [PATCH] net: ne2000: fix bounds check in ioport operations

From: Prasad J Pandit Hello, An OOB r/w issue in ne2000 device emulation was reported by Mr Ling Liu, CC'd here. The issue occurs while doing ne2000 ioport r/w operations, due to incorrect array bounds checks. Below is a proposed (tested)patch to fix this issue. Does it look okay? Thank you. -

[Qemu-devel] [PATVH v2] net: ne2000: fix bounds check in ioport operations

From: Prasad J Pandit While doing ioport r/w operations, ne2000 device emulation suffers from OOB r/w errors. Update respective array bounds check to avoid OOB access. Reported-by: Ling Liu Signed-off-by: Prasad J Pandit --- hw/net/ne2000.c | 28 +++- 1 file changed, 1

Re: [Qemu-devel] [PATVH v2] net: ne2000: fix bounds check in ioport operations

+-- On Thu, 31 Dec 2015, Jason Wang wrote --+ | > -(addr >= NE2000_PMEM_START && addr < NE2000_MEM_SIZE)) { | > +if (addr < 32 || (addr >= NE2000_PMEM_START && addr < NE2000_MEM_SIZE)) { | | The change is unnecessary. Okay. | > +if (addr < 32 | > +|| (addr >= NE2000_P

[Qemu-devel] [PATCH v3] net: ne2000: fix bounds check in ioport operations

From: Prasad J Pandit While doing ioport r/w operations, ne2000 device emulation suffers from OOB r/w errors. Update respective array bounds check to avoid OOB access. Reported-by: Ling Liu Signed-off-by: Prasad J Pandit --- hw/net/ne2000.c | 10 ++ 1 file changed, 6 insertions(+), 4

  1   2   3   4   5   6   7   8   9   10   >