From: Jerome Pouiller <Jerome.Pouiller@silabs.com> To: Al Viro <viro@zeniv.linux.org.uk> Cc: Jules Irenge <jbi.octave@gmail.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>, "Boqun.Feng@microsoft.com" <Boqun.Feng@microsoft.com> Subject: Re: [PATCH] staging: wfx: add gcc extension __force cast Date: Tue, 12 Nov 2019 12:00:41 +0000 [thread overview] Message-ID: <1714567.V28SpQSAGH@pc-42> (raw) In-Reply-To: <20191111231659.GA22837@ZenIV.linux.org.uk> On Tuesday 12 November 2019 00:16:59 CET Al Viro wrote: [...] > More fun: > int hif_read_mib(struct wfx_dev *wdev, int vif_id, u16 mib_id, void *val, size_t val_len) > { > int ret; > struct hif_msg *hif; > int buf_len = sizeof(struct hif_cnf_read_mib) + val_len; > struct hif_req_read_mib *body = wfx_alloc_hif(sizeof(*body), &hif); > struct hif_cnf_read_mib *reply = kmalloc(buf_len, GFP_KERNEL); > > OK, allocated request and reply buffers, by the look of it; request one > being struct hif_msg with struct hif_req_read_mib for payload > and reply - struct hif_cnf_read_mib { > uint32_t status; > uint16_t mib_id; > uint16_t length; > uint8_t mib_data[]; > } with val_len bytes in mib_data. > > body->mib_id = cpu_to_le16(mib_id); > wfx_fill_header(hif, vif_id, HIF_REQ_ID_READ_MIB, sizeof(*body)); > > Filled request, {.len = cpu_to_le16(4 + 4), > .id = HIF_REQ_ID_READ_MIB, > .interface = vif_id, > .body = { > .mib_id = cpu_to_le16(mib_id) > } > } > Note that mib_id is host-endian here; what we send is little-endian. > > ret = wfx_cmd_send(wdev, hif, reply, buf_len, false); > send it, get reply > > if (!ret && mib_id != reply->mib_id) { > Wha...? Now we are comparing two bytes at offset 4 into reply with a host-endian > value? Oh, well... Agree. > > dev_warn(wdev->dev, "%s: confirmation mismatch request\n", __func__); > ret = -EIO; > } > if (ret == -ENOMEM) > dev_err(wdev->dev, "buffer is too small to receive %s (%zu < %d)\n", > get_mib_name(mib_id), val_len, reply->length); > if (!ret) > memcpy(val, &reply->mib_data, reply->length); > What. The. Hell? > > We are copying data from the reply. Into caller-supplied object. > With length taken from the same reply and no validation even > attempted? Not even "um, maybe we shouldn't copy more than the caller > told us to copy, especially since that's as much as there is in the > source of that memcpy"? In fact, hif_generic_confirm() check that data from hardware is smaller than "buf_len". If it is not the case, ret will contains -ENOMEM. But indeed, if size of data is correct but reply->length is corrupted, we will have big trouble. (In add, I am not sure that -ENOMEM is well chosen for this case) > And that's besides the endianness questions. Note that getting the > endianness wrong here is just about certain to blow up - small value > will be misinterpreted by factor of 256. > > In any case, even if this is talking to firmware on a card, that's > an unhealthy degree of trust, especially since the same function > does consider the possibility of bogus replies. It is obvious that the errors paths have not been sufficiently checked. If you continue to search, I think you will find many similar problems. I will update the TODO list attached to the driver. -- Jérôme Pouiller
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Pouiller <Jerome.Pouiller@silabs.com> To: Al Viro <viro@zeniv.linux.org.uk> Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, Jules Irenge <jbi.octave@gmail.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Boqun.Feng@microsoft.com" <Boqun.Feng@microsoft.com> Subject: Re: [PATCH] staging: wfx: add gcc extension __force cast Date: Tue, 12 Nov 2019 12:00:41 +0000 [thread overview] Message-ID: <1714567.V28SpQSAGH@pc-42> (raw) In-Reply-To: <20191111231659.GA22837@ZenIV.linux.org.uk> On Tuesday 12 November 2019 00:16:59 CET Al Viro wrote: [...] > More fun: > int hif_read_mib(struct wfx_dev *wdev, int vif_id, u16 mib_id, void *val, size_t val_len) > { > int ret; > struct hif_msg *hif; > int buf_len = sizeof(struct hif_cnf_read_mib) + val_len; > struct hif_req_read_mib *body = wfx_alloc_hif(sizeof(*body), &hif); > struct hif_cnf_read_mib *reply = kmalloc(buf_len, GFP_KERNEL); > > OK, allocated request and reply buffers, by the look of it; request one > being struct hif_msg with struct hif_req_read_mib for payload > and reply - struct hif_cnf_read_mib { > uint32_t status; > uint16_t mib_id; > uint16_t length; > uint8_t mib_data[]; > } with val_len bytes in mib_data. > > body->mib_id = cpu_to_le16(mib_id); > wfx_fill_header(hif, vif_id, HIF_REQ_ID_READ_MIB, sizeof(*body)); > > Filled request, {.len = cpu_to_le16(4 + 4), > .id = HIF_REQ_ID_READ_MIB, > .interface = vif_id, > .body = { > .mib_id = cpu_to_le16(mib_id) > } > } > Note that mib_id is host-endian here; what we send is little-endian. > > ret = wfx_cmd_send(wdev, hif, reply, buf_len, false); > send it, get reply > > if (!ret && mib_id != reply->mib_id) { > Wha...? Now we are comparing two bytes at offset 4 into reply with a host-endian > value? Oh, well... Agree. > > dev_warn(wdev->dev, "%s: confirmation mismatch request\n", __func__); > ret = -EIO; > } > if (ret == -ENOMEM) > dev_err(wdev->dev, "buffer is too small to receive %s (%zu < %d)\n", > get_mib_name(mib_id), val_len, reply->length); > if (!ret) > memcpy(val, &reply->mib_data, reply->length); > What. The. Hell? > > We are copying data from the reply. Into caller-supplied object. > With length taken from the same reply and no validation even > attempted? Not even "um, maybe we shouldn't copy more than the caller > told us to copy, especially since that's as much as there is in the > source of that memcpy"? In fact, hif_generic_confirm() check that data from hardware is smaller than "buf_len". If it is not the case, ret will contains -ENOMEM. But indeed, if size of data is correct but reply->length is corrupted, we will have big trouble. (In add, I am not sure that -ENOMEM is well chosen for this case) > And that's besides the endianness questions. Note that getting the > endianness wrong here is just about certain to blow up - small value > will be misinterpreted by factor of 256. > > In any case, even if this is talking to firmware on a card, that's > an unhealthy degree of trust, especially since the same function > does consider the possibility of bogus replies. It is obvious that the errors paths have not been sufficiently checked. If you continue to search, I think you will find many similar problems. I will update the TODO list attached to the driver. -- Jérôme Pouiller _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2019-11-12 12:00 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-08 23:38 [PATCH] staging: wfx: add gcc extension __force cast Jules Irenge 2019-11-08 23:38 ` Jules Irenge 2019-11-09 8:36 ` Greg KH 2019-11-09 8:36 ` Greg KH 2019-11-09 9:19 ` Al Viro 2019-11-09 9:19 ` Al Viro 2019-11-11 13:51 ` Jules Irenge 2019-11-11 13:51 ` Jules Irenge 2019-11-11 20:28 ` Al Viro 2019-11-11 20:28 ` Al Viro 2019-11-11 23:16 ` Al Viro 2019-11-11 23:16 ` Al Viro 2019-11-12 12:00 ` Jerome Pouiller [this message] 2019-11-12 12:00 ` Jerome Pouiller 2019-11-12 11:32 ` Jerome Pouiller 2019-11-12 11:32 ` Jerome Pouiller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1714567.V28SpQSAGH@pc-42 \ --to=jerome.pouiller@silabs.com \ --cc=Boqun.Feng@microsoft.com \ --cc=devel@driverdev.osuosl.org \ --cc=gregkh@linuxfoundation.org \ --cc=jbi.octave@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.