WARNINGs mean kernel bugs.
The one in ucma_write() points to user programming error
or a malicious attempt. This is not a kernel bug, remove it.
BUG/WARNs that are not kernel bugs hinder automated testing effots.
Signed-off-by: Dmitry Vyukov <[email protected]>
Cc: Doug Ledford <[email protected]>
Cc: Sean Hefty <[email protected]>
Cc: Hal Rosenstock <[email protected]>
Cc: Leon Romanovsky <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
Changes since v1:
- added printk_once
---
drivers/infiniband/core/ucma.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
index 9520154..405d0ce 100644
--- a/drivers/infiniband/core/ucma.c
+++ b/drivers/infiniband/core/ucma.c
@@ -1584,8 +1584,11 @@ static ssize_t ucma_write(struct file *filp, const char __user *buf,
struct rdma_ucm_cmd_hdr hdr;
ssize_t ret;
- if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
+ if (!ib_safe_file_access(filp)) {
+ printk_once("ucma_write: process %d (%s) tried to do something hinky\n",
+ task_tgid_vnr(current), current->comm);
return -EACCES;
+ }
if (len < sizeof(hdr))
return -EINVAL;
--
2.8.0.rc3.226.g39d4020
On Mon, 21 Nov 2016, Dmitry Vyukov wrote:
> WARNINGs mean kernel bugs.
> The one in ucma_write() points to user programming error
> or a malicious attempt. This is not a kernel bug, remove it.
>
> BUG/WARNs that are not kernel bugs hinder automated testing effots.
>
> Signed-off-by: Dmitry Vyukov <[email protected]>
> Cc: Doug Ledford <[email protected]>
> Cc: Sean Hefty <[email protected]>
> Cc: Hal Rosenstock <[email protected]>
> Cc: Leon Romanovsky <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
>
> ---
> Changes since v1:
> - added printk_once
> ---
> drivers/infiniband/core/ucma.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
> index 9520154..405d0ce 100644
> --- a/drivers/infiniband/core/ucma.c
> +++ b/drivers/infiniband/core/ucma.c
> @@ -1584,8 +1584,11 @@ static ssize_t ucma_write(struct file *filp, const char __user *buf,
> struct rdma_ucm_cmd_hdr hdr;
> ssize_t ret;
>
> - if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
> + if (!ib_safe_file_access(filp)) {
> + printk_once("ucma_write: process %d (%s) tried to do something hinky\n",
> + task_tgid_vnr(current), current->comm);
> return -EACCES;
> + }
>
> if (len < sizeof(hdr))
> return -EINVAL;
FWIW, WARN_ON_ONCE came with commit e6bd18f57aad ("IB/security: Restrict
use of the write() interface"). Would it make sense to change the other
places as well?
Regards,
Miroslav
On Mon, Nov 21, 2016 at 11:25 AM, Miroslav Benes <[email protected]> wrote:
> On Mon, 21 Nov 2016, Dmitry Vyukov wrote:
>
>> WARNINGs mean kernel bugs.
>> The one in ucma_write() points to user programming error
>> or a malicious attempt. This is not a kernel bug, remove it.
>>
>> BUG/WARNs that are not kernel bugs hinder automated testing effots.
>>
>> Signed-off-by: Dmitry Vyukov <[email protected]>
>> Cc: Doug Ledford <[email protected]>
>> Cc: Sean Hefty <[email protected]>
>> Cc: Hal Rosenstock <[email protected]>
>> Cc: Leon Romanovsky <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>>
>> ---
>> Changes since v1:
>> - added printk_once
>> ---
>> drivers/infiniband/core/ucma.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
>> index 9520154..405d0ce 100644
>> --- a/drivers/infiniband/core/ucma.c
>> +++ b/drivers/infiniband/core/ucma.c
>> @@ -1584,8 +1584,11 @@ static ssize_t ucma_write(struct file *filp, const char __user *buf,
>> struct rdma_ucm_cmd_hdr hdr;
>> ssize_t ret;
>>
>> - if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
>> + if (!ib_safe_file_access(filp)) {
>> + printk_once("ucma_write: process %d (%s) tried to do something hinky\n",
>> + task_tgid_vnr(current), current->comm);
>> return -EACCES;
>> + }
>>
>> if (len < sizeof(hdr))
>> return -EINVAL;
>
> FWIW, WARN_ON_ONCE came with commit e6bd18f57aad ("IB/security: Restrict
> use of the write() interface"). Would it make sense to change the other
> places as well?
I guess so.
Can I ask somebody of infiniband maintainers to take care of this?
I just hit the warning in my automated testing environment when a
thread executed key_add in between open and write, then spent some
time debugging to figure out that this is an "invalid user input"
rather than a kernel bug.
On Mon, Nov 21, 2016 at 11:30:21AM +0100, Dmitry Vyukov wrote:
> On Mon, Nov 21, 2016 at 11:25 AM, Miroslav Benes <[email protected]> wrote:
> > On Mon, 21 Nov 2016, Dmitry Vyukov wrote:
> >
> >> WARNINGs mean kernel bugs.
> >> The one in ucma_write() points to user programming error
> >> or a malicious attempt. This is not a kernel bug, remove it.
> >>
> >> BUG/WARNs that are not kernel bugs hinder automated testing effots.
> >>
> >> Signed-off-by: Dmitry Vyukov <[email protected]>
> >> Cc: Doug Ledford <[email protected]>
> >> Cc: Sean Hefty <[email protected]>
> >> Cc: Hal Rosenstock <[email protected]>
> >> Cc: Leon Romanovsky <[email protected]>
> >> Cc: [email protected]
> >> Cc: [email protected]
> >> Cc: [email protected]
> >>
> >> ---
> >> Changes since v1:
> >> - added printk_once
> >> ---
> >> drivers/infiniband/core/ucma.c | 5 ++++-
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
> >> index 9520154..405d0ce 100644
> >> --- a/drivers/infiniband/core/ucma.c
> >> +++ b/drivers/infiniband/core/ucma.c
> >> @@ -1584,8 +1584,11 @@ static ssize_t ucma_write(struct file *filp, const char __user *buf,
> >> struct rdma_ucm_cmd_hdr hdr;
> >> ssize_t ret;
> >>
> >> - if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
> >> + if (!ib_safe_file_access(filp)) {
> >> + printk_once("ucma_write: process %d (%s) tried to do something hinky\n",
> >> + task_tgid_vnr(current), current->comm);
> >> return -EACCES;
> >> + }
> >>
> >> if (len < sizeof(hdr))
> >> return -EINVAL;
> >
> > FWIW, WARN_ON_ONCE came with commit e6bd18f57aad ("IB/security: Restrict
> > use of the write() interface"). Would it make sense to change the other
> > places as well?
>
>
> I guess so.
> Can I ask somebody of infiniband maintainers to take care of this?
Please see below,
Hope it helps.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 21, 2016 at 12:44 PM, Leon Romanovsky <[email protected]> wrote:
> On Mon, Nov 21, 2016 at 11:30:21AM +0100, Dmitry Vyukov wrote:
>> On Mon, Nov 21, 2016 at 11:25 AM, Miroslav Benes <[email protected]> wrote:
>> > On Mon, 21 Nov 2016, Dmitry Vyukov wrote:
>> >
>> >> WARNINGs mean kernel bugs.
>> >> The one in ucma_write() points to user programming error
>> >> or a malicious attempt. This is not a kernel bug, remove it.
>> >>
>> >> BUG/WARNs that are not kernel bugs hinder automated testing effots.
>> >>
>> >> Signed-off-by: Dmitry Vyukov <[email protected]>
>> >> Cc: Doug Ledford <[email protected]>
>> >> Cc: Sean Hefty <[email protected]>
>> >> Cc: Hal Rosenstock <[email protected]>
>> >> Cc: Leon Romanovsky <[email protected]>
>> >> Cc: [email protected]
>> >> Cc: [email protected]
>> >> Cc: [email protected]
>> >>
>> >> ---
>> >> Changes since v1:
>> >> - added printk_once
>> >> ---
>> >> drivers/infiniband/core/ucma.c | 5 ++++-
>> >> 1 file changed, 4 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
>> >> index 9520154..405d0ce 100644
>> >> --- a/drivers/infiniband/core/ucma.c
>> >> +++ b/drivers/infiniband/core/ucma.c
>> >> @@ -1584,8 +1584,11 @@ static ssize_t ucma_write(struct file *filp, const char __user *buf,
>> >> struct rdma_ucm_cmd_hdr hdr;
>> >> ssize_t ret;
>> >>
>> >> - if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
>> >> + if (!ib_safe_file_access(filp)) {
>> >> + printk_once("ucma_write: process %d (%s) tried to do something hinky\n",
>> >> + task_tgid_vnr(current), current->comm);
>> >> return -EACCES;
>> >> + }
>> >>
>> >> if (len < sizeof(hdr))
>> >> return -EINVAL;
>> >
>> > FWIW, WARN_ON_ONCE came with commit e6bd18f57aad ("IB/security: Restrict
>> > use of the write() interface"). Would it make sense to change the other
>> > places as well?
>>
>>
>> I guess so.
>> Can I ask somebody of infiniband maintainers to take care of this?
>
> Please see below,
> Hope it helps.
In ib_ucm_write function there is a wrong prefix:
+ pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
Otherwise looks good. Thanks.
On Mon, Nov 21, 2016 at 12:48:35PM +0100, Dmitry Vyukov wrote:
> On Mon, Nov 21, 2016 at 12:44 PM, Leon Romanovsky <[email protected]> wrote:
> > On Mon, Nov 21, 2016 at 11:30:21AM +0100, Dmitry Vyukov wrote:
> >> On Mon, Nov 21, 2016 at 11:25 AM, Miroslav Benes <[email protected]> wrote:
> >> > On Mon, 21 Nov 2016, Dmitry Vyukov wrote:
> >> >
> >> >> WARNINGs mean kernel bugs.
> >> >> The one in ucma_write() points to user programming error
> >> >> or a malicious attempt. This is not a kernel bug, remove it.
> >> >>
> >> >> BUG/WARNs that are not kernel bugs hinder automated testing effots.
> >> >>
> >> >> Signed-off-by: Dmitry Vyukov <[email protected]>
> >> >> Cc: Doug Ledford <[email protected]>
> >> >> Cc: Sean Hefty <[email protected]>
> >> >> Cc: Hal Rosenstock <[email protected]>
> >> >> Cc: Leon Romanovsky <[email protected]>
> >> >> Cc: [email protected]
> >> >> Cc: [email protected]
> >> >> Cc: [email protected]
> >> >>
> >> >> ---
> >> >> Changes since v1:
> >> >> - added printk_once
> >> >> ---
> >> >> drivers/infiniband/core/ucma.c | 5 ++++-
> >> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/infiniband/core/ucma.c b/drivers/infiniband/core/ucma.c
> >> >> index 9520154..405d0ce 100644
> >> >> --- a/drivers/infiniband/core/ucma.c
> >> >> +++ b/drivers/infiniband/core/ucma.c
> >> >> @@ -1584,8 +1584,11 @@ static ssize_t ucma_write(struct file *filp, const char __user *buf,
> >> >> struct rdma_ucm_cmd_hdr hdr;
> >> >> ssize_t ret;
> >> >>
> >> >> - if (WARN_ON_ONCE(!ib_safe_file_access(filp)))
> >> >> + if (!ib_safe_file_access(filp)) {
> >> >> + printk_once("ucma_write: process %d (%s) tried to do something hinky\n",
> >> >> + task_tgid_vnr(current), current->comm);
> >> >> return -EACCES;
> >> >> + }
> >> >>
> >> >> if (len < sizeof(hdr))
> >> >> return -EINVAL;
> >> >
> >> > FWIW, WARN_ON_ONCE came with commit e6bd18f57aad ("IB/security: Restrict
> >> > use of the write() interface"). Would it make sense to change the other
> >> > places as well?
> >>
> >>
> >> I guess so.
> >> Can I ask somebody of infiniband maintainers to take care of this?
> >
> > Please see below,
> > Hope it helps.
>
> In ib_ucm_write function there is a wrong prefix:
>
> + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
I did it intentionally to have the same errors for all flows.
>
> Otherwise looks good. Thanks.
On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote:
> >
> > In ib_ucm_write function there is a wrong prefix:
> >
> > + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
>
> I did it intentionally to have the same errors for all flows.
Lets actually use a good message too please?
pr_err_once("ucm_write: process %d (%s) changed security contexts after opening FD, this is not allowed.\n",
Jason
On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote:
> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote:
> > >
> > > In ib_ucm_write function there is a wrong prefix:
> > >
> > > + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
> >
> > I did it intentionally to have the same errors for all flows.
>
> Lets actually use a good message too please?
>
> pr_err_once("ucm_write: process %d (%s) changed security contexts after opening FD, this is not allowed.\n",
>
> Jason
On 11/21/2016 12:38 PM, Leon Romanovsky wrote:
> On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote:
>> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote:
>>>>
>>>> In ib_ucm_write function there is a wrong prefix:
>>>>
>>>> + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
>>>
>>> I did it intentionally to have the same errors for all flows.
>>
>> Lets actually use a good message too please?
>>
>> pr_err_once("ucm_write: process %d (%s) changed security contexts after opening FD, this is not allowed.\n",
>>
>> Jason
I applied Leon's reworked version of this patch, thanks.
--
Doug Ledford <[email protected]>
GPG Key ID: 0E572FDD
On Wed, Dec 14, 2016 at 01:16:45PM -0500, Doug Ledford wrote:
> On 11/21/2016 12:38 PM, Leon Romanovsky wrote:
> > On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote:
> >> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote:
> >>>>
> >>>> In ib_ucm_write function there is a wrong prefix:
> >>>>
> >>>> + pr_err_once("ucm_write: process %d (%s) tried to do something hinky\n",
> >>>
> >>> I did it intentionally to have the same errors for all flows.
> >>
> >> Lets actually use a good message too please?
> >>
> >> pr_err_once("ucm_write: process %d (%s) changed security contexts after opening FD, this is not allowed.\n",
> >>
> >> Jason
>
> I applied Leon's reworked version of this patch, thanks.
Thanks Doug,
I already forgot about it :)
>
> --
> Doug Ledford <[email protected]>
> GPG Key ID: 0E572FDD
>