linux-kernel - Re: repeated bugs in new rtl wifi drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54123EC8.1040906@lwfinger.net>
Date:	Thu, 11 Sep 2014 19:31:04 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Kees Cook <keescook@...omium.org>
CC:	"John W. Linville" <linville@...driver.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: repeated bugs in new rtl wifi drivers

On 09/11/2014 06:50 PM, Kees Cook wrote:
> On Thu, Sep 11, 2014 at 4:38 PM, Larry Finger <Larry.Finger@...inger.net> wrote:
>> On 09/11/2014 05:27 PM, Kees Cook wrote:
>>>
>>> Hi,
>>>
>>> I keep fixing this same bug that keeps showing up in the rtl wifi
>>> drivers. CL_PRINTF keeps getting redefined (incorrectly) instead of
>>> using a correctly fixed global. Is there a way to stop this from
>>> happening again?
>>>
>>> Here are the past three (identical) fixes I've landed:
>>> a3355a62673e2c4bd8617d2f07c8edee92a89b8d
>>> 037526f1ae7eeff5cf27ad790ebfe30303eeebe8
>>> 6437f51ec36af8ef1e3e2659439b35c37e5498e2
>>>
>>> And the buildbot report below seems to show there are more to be made. :)
>>
>>
>> Sorry that I missed your fix. I should have seen it come through Linville's
>> list. I will push your fix through again.
>
> Well, I should clarify: it's not getting unfixed/reverted, but rather,
> it hasn't been consolidated to avoid needing the code again in the
> future. All three of the fixes above are on almost identical header
> files. If we could consolidate them, that would be great, and it would
> keep things much nicer.

The two in staging are there because there was need to have those two driver 
available as quickly as possible. Even though a lot of code is the same as the 
regular tree, there were enough differences that it has taken a lot of work to 
merge those two new drivers into the wireless tree. It is part of that effort 
that ended up effectively reverting your fix for the wireless tree.

My plan is to ultimately eliminate all the CL_SNPRINTF and CL_PRINTF stuff. In 
every case I have seen, the two are paired, thus they can be replaced with a 
simple "pr_info". Now that we are unifying the Realtek and kernel codes, I need 
to check with the Realtek guys.

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/