linux-kernel - Re: [PATCH v3] staging: wlan-ng: replace rate macros

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]

Date:   Tue, 18 Apr 2023 21:38:57 +0200
From:   Luke Koch <lu.ale.koch@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     error27@...il.com, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] staging: wlan-ng: replace rate macros

On Tue, Apr 18, 2023 at 03:04:06PM +0200, Greg KH wrote:
> This patch implies that these structures are set but never actually read
> from, so why are they present at all?  Is this a structure that is on
> the wire/air or used somewhere else as an api to hardware?

I never looked that far as I was naively trying to just fix the
checkpatch warning. They seem to be part of MAC frames coming from the
hardware.

> I tried to unwind things in the driver, but couldn't figure it out, what
> happens if you just delete these fields, does the driver still work
> properly?

It compiles without issue when deleting these structs, but almost
certainly breaks the driver since it changes what the resulting message
looks like in memory. I assume the caller of the function uses the message for
something - otherwise setting all the message parameters wouldn't make any sense
at all - and changing the message like this would cause major problems.

The structs seem necessary, but changing how they are accessed to using
arrays shouldn't introduce any issues as resulting values as well as addresses
in relation to the message struct will be unchanged.

Best regards,

Luke Koch