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] [day] [month] [year] [list]
Date:   Sun, 6 Nov 2022 22:39:25 +0530
From:   Deepak R Varma <drv@...lo.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Larry Finger <Larry.Finger@...inger.net>,
        Phillip Potter <phil@...lpotter.co.uk>,
        Pavel Skripkin <paskripkin@...il.com>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: r8188eu: simplify complex pointer casting

On Sun, Nov 06, 2022 at 05:43:38PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Nov 06, 2022 at 01:56:01PM +0530, Deepak R Varma wrote:
> > Pointers to structures udphdr and dhcpMessage are derived by casting
> > adjacent pointers with size_t. Such typecast of pointer using size_t
> > is not preferred. The code looks complex and delicate. Simplify such
> > casting by utilizing generic "void *" casting.
> > While at this change, remove the unnecessary __be32 casting for member
> > variable "cookie".
>
> Wait, why is that unecessary?

Hello Greg,
cookie is already defined to be a __be32 type as part of the dhcpMesssade
structure declared in the same file.

 15 struct dhcpMessage {
 14         u_int8_t op;
  1         u_int8_t file[128];
597         __be32 cookie;
  1         u_int8_t options[308]; /* 312 - cookie */
  2 };
  3

>
> And why is that part of this change, that should be a separate one, so
> that it can be reverted when it's found to be buggy :)

Sounds good. I will submit that as a separate patch.
>
> >
> > Suggested-by: Joe Perches <joe@...ches.com>
> > Signed-off-by: Deepak R Varma <drv@...lo.com>
> > ---
> >  drivers/staging/r8188eu/core/rtw_br_ext.c | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/r8188eu/core/rtw_br_ext.c b/drivers/staging/r8188eu/core/rtw_br_ext.c
> > index a23f7df373ed..e9b0906d0d74 100644
> > --- a/drivers/staging/r8188eu/core/rtw_br_ext.c
> > +++ b/drivers/staging/r8188eu/core/rtw_br_ext.c
> > @@ -610,13 +610,15 @@ void dhcp_flag_bcast(struct adapter *priv, struct sk_buff *skb)
> >  			struct iphdr *iph = (struct iphdr *)(skb->data + ETH_HLEN);
> >
> >  			if (iph->protocol == IPPROTO_UDP) { /*  UDP */
> > -				struct udphdr *udph = (struct udphdr *)((size_t)iph + (iph->ihl << 2));
> > +				struct udphdr *udph = (void *)iph + (iph->ihl << 2);
> >
> >  				if ((udph->source == htons(CLIENT_PORT)) &&
> >  				    (udph->dest == htons(SERVER_PORT))) { /*  DHCP request */
> > -					struct dhcpMessage *dhcph =
> > -						(struct dhcpMessage *)((size_t)udph + sizeof(struct udphdr));
> > -					u32 cookie = be32_to_cpu((__be32)dhcph->cookie);
> > +					u32 cookie;
> > +					struct dhcpMessage *dhcph;
>
> Why reorder these variables?

No specific reason. Since next instruction is associated with *dhcph, I thought
it will simpler to follow. I will revise and resend.

>
> > +
> > +					dhcph = (void *)udph + sizeof(struct udphdr);
> > +					cookie = be32_to_cpu(dhcph->cookie);
>
> The cookie change should be separate please.

Sounds good. Will split the patch into a patch set and resubmit.
>
> thanks,
>
> greg k-h
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ