Re: A potential bug in drivers/usb/gadget/udc/m66592-udc.ko
Hi, Pavel Andrianov <andria...@ispras.ru> writes: > Hi! > > There is a potential bug in drivers/usb/gadget/udc/m66592-udc.ko. > In m66592_probe interrupts are requested at line 1612. After that > initialization of common resources is continued. For example, in > > -> usb_add_gadget_udc (line 1678) >-> usb_add_gadget_udc_release > -> udc_bind_to_driver >-> usb_gadget_udc_start > -> m66592_udc_start > > m66592->driver is set. In interrupt handler the data is used, thus if > interrupt comes before udc_start is executed, null pointer dereference > occurs. > Should the call of request_irq be after complete initialization? interrupts will only fire after we connect data pullups, that's done by ->pullup() method wy later ;-) -- balbi signature.asc Description: PGP signature
Re: A potential bug in drivers/usb/gadget/udc/m66592-udc.ko
Hi, Pavel Andrianov writes: > Hi! > > There is a potential bug in drivers/usb/gadget/udc/m66592-udc.ko. > In m66592_probe interrupts are requested at line 1612. After that > initialization of common resources is continued. For example, in > > -> usb_add_gadget_udc (line 1678) >-> usb_add_gadget_udc_release > -> udc_bind_to_driver >-> usb_gadget_udc_start > -> m66592_udc_start > > m66592->driver is set. In interrupt handler the data is used, thus if > interrupt comes before udc_start is executed, null pointer dereference > occurs. > Should the call of request_irq be after complete initialization? interrupts will only fire after we connect data pullups, that's done by ->pullup() method wy later ;-) -- balbi signature.asc Description: PGP signature
A potential bug in drivers/usb/gadget/udc/m66592-udc.ko
Hi! There is a potential bug in drivers/usb/gadget/udc/m66592-udc.ko. In m66592_probe interrupts are requested at line 1612. After that initialization of common resources is continued. For example, in -> usb_add_gadget_udc (line 1678) -> usb_add_gadget_udc_release -> udc_bind_to_driver -> usb_gadget_udc_start -> m66592_udc_start m66592->driver is set. In interrupt handler the data is used, thus if interrupt comes before udc_start is executed, null pointer dereference occurs. Should the call of request_irq be after complete initialization? -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
A potential bug in drivers/usb/gadget/udc/m66592-udc.ko
Hi! There is a potential bug in drivers/usb/gadget/udc/m66592-udc.ko. In m66592_probe interrupts are requested at line 1612. After that initialization of common resources is continued. For example, in -> usb_add_gadget_udc (line 1678) -> usb_add_gadget_udc_release -> udc_bind_to_driver -> usb_gadget_udc_start -> m66592_udc_start m66592->driver is set. In interrupt handler the data is used, thus if interrupt comes before udc_start is executed, null pointer dereference occurs. Should the call of request_irq be after complete initialization? -- Pavel Andrianov Linux Verification Center, ISPRAS web: http://linuxtesting.org e-mail: andria...@ispras.ru
