[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181204204508.3ebead06@alans-desktop>
Date: Tue, 4 Dec 2018 20:45:08 +0000
From: Alan Cox <gnomes@...rguk.ukuu.org.uk>
To: Jian-Hong Pan <starnight@...cu.edu.tw>
Cc: Andreas Färber <afaerber@...e.de>,
"David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Marcel Holtmann <marcel@...tmann.org>,
Dollar Chen <dollar.chen@...ec.com>,
Ken Yu <ken.yu@...wireless.com>, linux-wpan@...r.kernel.org,
Stefan Schmidt <stefan@...enfreihafen.org>
Subject: Re: [PATCH V4 5/6] net: maclorawan: Implement maclorawan class
module
> +void
> +lrw_parse_frame(struct lrw_session *ss, struct sk_buff *skb)
> +{
> + struct lrw_fhdr *fhdr = &ss->rx_fhdr;
> + __le16 *p_fcnt;
> +
> + pr_debug("%s: %s\n", LORAWAN_MODULE_NAME, __func__);
> +
> + /* Get message type */
> + fhdr->mtype = skb->data[0];
> + skb_pull(skb, LRW_MHDR_LEN);
This does not seem robust. There is no point at which you actually check
the message size is valid etc
> + fhdr->fopts_len = fhdr->fctrl & 0xF;
> + if (fhdr->fopts_len > 0) {
> + memcpy(fhdr->fopts, skb->data, fhdr->fopts_len);
> + skb_pull(skb, fhdr->fopts_len);
> + }
In fact you appear to copy random kernel memory into a buffer
> +
> + /* TODO: Parse frame options */
> +
> + /* Remove message integrity code */
> + skb_trim(skb, skb->len - LRW_MIC_LEN);
and then try and trim the buffer to a negative size ?
Alan
Powered by blists - more mailing lists