Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1443376 > unrolled thread
| Started by | Dan Carpenter <dan.carpenter@oracle.com> |
|---|---|
| First post | 2016-07-14 13:40 +0200 |
| Last post | 2016-07-15 10:40 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
[patch] netiucv: silence an underflow warning Dan Carpenter <dan.carpenter@oracle.com> - 2016-07-14 13:40 +0200
Re: [patch] netiucv: silence an underflow warning Ursula Braun <ubraun@linux.vnet.ibm.com> - 2016-07-15 09:20 +0200
Re: [patch] netiucv: silence an underflow warning Dan Carpenter <dan.carpenter@oracle.com> - 2016-07-15 10:40 +0200
| From | Dan Carpenter <dan.carpenter@oracle.com> |
|---|---|
| Date | 2016-07-14 13:40 +0200 |
| Subject | [patch] netiucv: silence an underflow warning |
| Message-ID | <rUN9L-G3-17@gated-at.bofh.it> |
I haven't looked at the implications but we accidentally allow bs1 to
be negative. It makes my static checker complain.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
index b0e8ffd..85a5744 100644
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -1578,7 +1578,7 @@ static ssize_t buffer_write (struct device *dev, struct device_attribute *attr,
*e);
return -EINVAL;
}
- if (bs1 > NETIUCV_BUFSIZE_MAX) {
+ if (bs1 < 0 || bs1 > NETIUCV_BUFSIZE_MAX) {
IUCV_DBF_TEXT_(setup, 2,
"buffer_write: buffer size %d too large\n",
bs1);
[toc] | [next] | [standalone]
| From | Ursula Braun <ubraun@linux.vnet.ibm.com> |
|---|---|
| Date | 2016-07-15 09:20 +0200 |
| Message-ID | <rV5zH-3Xq-9@gated-at.bofh.it> |
| In reply to | #1443376 |
Hi Dan,
thanks for reporting this netiucv-problem. There is an implication:
Without fix, buffer values between 2**31 and 2**32 are not detected as
invalid values. Your fix would help, but since we have to touch the
code, I suggest to modernize it, moving from simple_strtoul() to
kstrtouint(). This would be the patch I have in mind:
--- a/drivers/s390/net/netiucv.c
+++ b/drivers/s390/net/netiucv.c
@@ -1564,21 +1564,21 @@ static ssize_t buffer_write (struct devi
{
struct netiucv_priv *priv = dev_get_drvdata(dev);
struct net_device *ndev = priv->conn->netdev;
- char *e;
- int bs1;
+ unsigned int bs1;
+ int rc;
IUCV_DBF_TEXT(trace, 3, __func__);
if (count >= 39)
return -EINVAL;
- bs1 = simple_strtoul(buf, &e, 0);
+ rc = kstrtouint(buf, 0, &bs1);
- if (e && (!isspace(*e))) {
- IUCV_DBF_TEXT_(setup, 2, "buffer_write: invalid char %02x\n",
- *e);
+ if (rc == -EINVAL) {
+ IUCV_DBF_TEXT_(setup, 2, "buffer_write: invalid char %s\n",
+ buf);
return -EINVAL;
}
- if (bs1 > NETIUCV_BUFSIZE_MAX) {
+ if ((rc == -ERANGE) || (bs1 > NETIUCV_BUFSIZE_MAX)) {
IUCV_DBF_TEXT_(setup, 2,
"buffer_write: buffer size %d too large\n",
bs1);
And a question about your static checker detecting this problem: Is it a
private checker, or something we could use as well?
Does your checker like my patch version?
Thanks, Ursula
On 07/14/2016 01:30 PM, Dan Carpenter wrote:
> I haven't looked at the implications but we accidentally allow bs1 to
> be negative. It makes my static checker complain.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/s390/net/netiucv.c b/drivers/s390/net/netiucv.c
> index b0e8ffd..85a5744 100644
> --- a/drivers/s390/net/netiucv.c
> +++ b/drivers/s390/net/netiucv.c
> @@ -1578,7 +1578,7 @@ static ssize_t buffer_write (struct device *dev, struct device_attribute *attr,
> *e);
> return -EINVAL;
> }
> - if (bs1 > NETIUCV_BUFSIZE_MAX) {
> + if (bs1 < 0 || bs1 > NETIUCV_BUFSIZE_MAX) {
> IUCV_DBF_TEXT_(setup, 2,
> "buffer_write: buffer size %d too large\n",
> bs1);
>
[toc] | [prev] | [next] | [standalone]
| From | Dan Carpenter <dan.carpenter@oracle.com> |
|---|---|
| Date | 2016-07-15 10:40 +0200 |
| Message-ID | <rV6P7-4CX-13@gated-at.bofh.it> |
| In reply to | #1443987 |
That looks good. Thanks. This was a Smatch thing that I haven't pushed yet. It needs some work yet to cut down the false positive rate but it's close. regards, dan carpenter
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web