Re: [PATCH] staging: rtl8712: prevent buffer overrun in recvbuf2recvframe

[Larry Finger <Larry.Finger@lwfinger.net>]

On 05/23/2015 12:24 PM, Haggai Eran wrote:
> On 20 May 2015 at 22:20, Haggai Eran <haggai.eran@gmail.com> wrote:
>> On 20 May 2015 at 19:39, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>> On 05/20/2015 01:17 AM, Haggai Eran wrote:
>>>>
>>>> On May 19, 2015 08:47, "Haggai Eran" <haggai.eran@gmail.com
>>>> <mailto:haggai.eran@gmail.com>> wrote:
>>>>   >
>>>>   > With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
>>>>   > packet are set, but the packet length is too large. Truncate the packet
>>>>   > to prevent memory corruption.
>>>>   >
>>>>   > Signed-off-by: Haggai Eran <haggai.eran@gmail.com
>>>> <mailto:haggai.eran@gmail.com>>
>>>>   > ---
>>>>   >
>>>>   > Hi,
>>>>   >
>>>>   > I think this solves the issue for me. I'll test it more thoroughly
>>>> later. I
>>>>   > still don't know why a fragmented packet has such a large pkt_len value
>>>> though.
>>>>   >
>>>>   > Thanks,
>>>>   > Haggai
>>>>   >
>>>>
>>>> I guess I was too quick with this patch. It prevents the kernel page
>>>> faults, but
>>>> with it I still see sometimes the connectivity disappear for a minute or
>>>> two.
>>>
>>>
>>> Is anything logged when that happens?
>> No. I get once in a while the other corrupted entries I told you
>> about, but nothing special to these freezes
>>
>>> I'm still trying to see where that magic number of 1658 comes from, and how
>>> that affects the RX buffer size.
>>
>> I tried to look at the new driver (rtl8192su), but it doesn't seem to
>> handle this more-fragment bit at all.
>>
>>> When I unconditionally set alloc_sz to tmp_len as in the attached patch (I
>>> remembered to refresh it this time), nothing bad has happened here yet. What
>>> happens on your box?
>>
>> The same freezes still occur.
>
> I think the freezes I saw weren't related to the same issue. I was
> running a debugging kernel, and I saw the same freezes also with a
> different wifi adaptor. After switching to a non-debugging kernel, and
> using your patch, the freezes stopped.

That is good news. Perhaps the debugging kernel is overflowing the stack. Did 
your debugging kernel have "Check for stack overflows" set in the "Memory 
Debugging" section of the configuration? I did not have that turned on until 
today, but it seems like a good idea.

Do you want to prepare the final version of the patch, or should I?

Larry