dlink,
actually use the right USB_MAX_STR_LENGTH define. I also fixed an
issue
I missed first time around.
Philippe De Swert (4):
libusbg: Fix readlink/buffer overrun issue. CID#56130, CID#56129
libusbg: Fix buffer overrun issue. CID#56128
libusbg: Do not try to dereference func when it is
Avoid calling usbg_read_string with a 40 byte long buffer, which in turn is
filled in
by usbg_read_buf which uses a maximum of USBG_MAX_STR_LENGTH which is 256 bytes.
Signed-off-by: Philippe De Swert
---
src/usbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/usbg.c
We check if func is NULL, so if the allocation function failed we should
not dereference or handle it anymore, so we jump straight to the end.
Signed-off-by: Philippe De Swert
---
src/usbg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/usbg.c b/src/usbg.c
index 66aa435..8ad6a9e
We probably need to check if we get valid attributes passed. Otherwise we will
try to dereference a NULL-pointer as the usb_config_attr will not be valid.
Signed-off-by: Philippe De Swert
---
src/usbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/usbg.c b/src/usbg.c
Readlink can return the total length of the buffer (here 4096), so we do not
want to dereference target[4096] as that would give an off by one error.
Signed-off-by: Philippe De Swert
---
src/usbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/usbg.c b/src/usbg.c
index
missed first time around.
Philippe De Swert (4):
libusbg: Fix readlink/buffer overrun issue. CID#56130, CID#56129
libusbg: Fix buffer overrun issue. CID#56128
libusbg: Do not try to dereference func when it is NULL. CID#56127
libusbg: Do not dereference usb config attributes when they are
Hello,
On 13/05/14 09:58, Krzysztof Opasiak wrote:
Please excuse me but I have missed this question yesterday.
No problem, I was helping a friend move so did not have time to answer
your other questions.;)
If you are talking about b returned from usbg_get_binding() don't be
afraid because
Hi,
On 12/05/14 09:58, Krzysztof Opasiak wrote:
Avoid calling usbg_read_string with a 40 byte long buffer, which in
turn is filled in
by usbg_read_buf which uses a maximum of USBG_MAX_LENGTH which is
256 bytes.
Signed-off-by: Philippe De Swert
---
src/usbg.c | 2 +-
1 file changed, 1
Hi,
On 12/05/14 09:52, Krzysztof Opasiak wrote:
I agree that there was a possible off-by-one-error and thank you for
catching this I have missed it, but maybe it is not the best solution?
When you put '\0' sign to target[nmb-1] you are solving off by one
problem but you always lose the last sign
Hi all,
On first sight it seems that the two things in the subject have nothing
to do with each other, so I will quickly explain why they do (at least
for me). So for some time already I have been working on usb_moded,
which is a small daemon which handles setting up gadget drivers, so that
a
Alan Stern for suggesting the correct test in this case.
Found with coverity: CID 744367, CID 145679
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/dummy_hcd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/ga
the correct one this time.
The second patch should now finally have the correct test.
Thank you Alan for your patience, I should really not make patches late at
night.
Philippe De Swert (2):
usb:gadget:dummy_hcd : Avoid infinite loop
usb:gadget:dummy_hcd : Detect port and link state
do so. We need to decrement first because the
adding at the current
index of i is the one that failed.
At the same time the code is harmonized for hcd platform adding.
Found with coverity : CID 751073
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/dummy_hcd.c | 8 +++-
1 f
DED
check in, but it might not be needed. I can update that if needed.
Thank you.
Philippe De Swert (2):
usb:gadget:dummy_hcd : Avoid infinite loop
usb:gadget:dummy_hcd : Detect port and link state correctly to avoid
unreachable code
drivers/usb/gadget/dummy_hcd.c | 14 +-
for suggesting the correct test in this case.
Found with coverity: CID 744367, CID 145679
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/dummy_hcd.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
i
do so. We need to decrement first because the
adding at the current
index of i is the one that failed.
At the same time the code is harmonized for hcd platform adding.
Found with coverity : CID 751073
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/dummy_hcd.c | 8 +++-
1 f
S_U0.
Found with coverity: CID 744367, CID 145679
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/dummy_hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 5c506fb..22cd01c 100644
--- a/drivers
These two patches fix some minor issues in the dummy_hcd driver. Both
errors were detected with the help of coverity analysis.
Philippe De Swert (2):
usb:gadget:dummy_hcd : Avoid infinite loop
usb:gadget:dummy_hcd : Detect port and link state correctly to avoid
unreachable code
drivers
so. We decrement first because the adding at
the current
index of i is the one that failed.
Found with coverity : CID 751073
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/dummy_hcd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/dummy_hcd.
Hi,
On 18/08/13 17:52, Alan Stern wrote:
Now there is some discussion about having a userpace library to handle
the creation of all the necessary files easily. But I cannot find a
trace of it. Does it exist already?
No mention of it has appeared on the mailing list.
From: https://lkml.org/lk
The documentation for the USB gadget fs is actually in
Documentation/usb/gadget_configfs.txt.
Signed-off-by: Philippe De Swert
---
drivers/usb/gadget/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 8e93683
Hi,
On 12/08/13 21:08, Felipe Balbi wrote:
On Fri, Aug 09, 2013 at 09:23:08PM +0300, Philippe De Swert wrote:
Some bad gadget drivers do not check the return status of usb_add_config.
fix the gadget driver
As stated in my comment (see below) that is indeed what should happen.
But we
argued that the faulty gadget driver should be fixed, but imho it is better
to avoid crashing the kernel and letting the gadget developer know he/she
is making a mistake. And have the developer of said gadget driver then fix
the problem of course.
Signed-off-by: Philippe De Swert
---
drivers/usb
Kernel reports a section mismatch when compiling in musb drivers.
This patch fixes that.
Signed-off-by: Philippe De Swert
---
drivers/usb/musb/musb_dma.h |2 +-
drivers/usb/musb/musbhsdma.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb
: Philippe De Swert
---
drivers/usb/musb/musb_core.c | 31 ++-
drivers/usb/musb/musbhsdma.h |4
drivers/usb/musb/omap2430.c | 22 ++
drivers/usb/musb/ux500.c | 22 ++
4 files changed, 46 insertions(+), 33 deletions
Hi all,
On 26/09/2012, Philippe De Swert wrote:
> Hi,
>
>>On Tue, Sep 25, 2012 at 2:39 PM, Philippe De Swert
>>>> Then maybe it's best to just remove the ifdefs and always provide
>>>> generic_interrupt() ?
>
Hi,
>On Tue, Sep 25, 2012 at 2:39 PM, Philippe De Swert
>>> Then maybe it's best to just remove the ifdefs and always provide
>>> generic_interrupt() ?
>>>
>>> Anyone against it ?
>
>Providing generic_inter
Hi,
On 25/09/2012, Felipe Balbi wrote:
>> > > Not a mention of CONFIG_SOC_OMAP2430 and CONFIG_SOC_OMAP3430 did not
>> > > get set (while it is not a 3430 but a 3630 I am using). Maybe
>> > > CONFIG_ARCH_OMAP3 would have been a better choice then?
>> >
>> > that's quite f**ked up. Tony, why doesn'
Hi,
On 24/09/2012, Felipe Balbi wrote:
> SoB's mail doesn't From mail.
Well still in the progress of migrating of my personal to work laptop.
Since the patch does not seem correct the replacement will have
matching addresses.
>> /*
29 matches
Mail list logo
