From: Doug Ledford <dledford@redhat.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Tatyana Nikolova <Tatyana.E.Nikolova@intel.com>,
swise@opengridcomputing.com, john.s.lacombe@intel.com,
linux-rdma@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] RDMA/core: Fix for parsing netlink string attribute
Date: Tue, 12 May 2015 13:14:26 -0400 [thread overview]
Message-ID: <1431450866.43876.65.camel@redhat.com> (raw)
In-Reply-To: <20150508215328.GB3917@obsidianresearch.com>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
On Fri, 2015-05-08 at 15:53 -0600, Jason Gunthorpe wrote:
> On Fri, May 08, 2015 at 04:36:33PM -0500, Tatyana Nikolova wrote:
> > The string iwpm_ulib_name is recorded in a nlmsg as a netlink attribute.
> > Without this fix parsing of the nlmsg by the userspace port mapper service fails
> > because of unknown attribute length, causing the port mapper service not to
> > register the client, which has sent the nlmsg.
>
> Reviewed-By: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>
> This actually will copy some kernel memory to userspace. I think the
> overflow is in .text, so probably not a security issue..
It shouldn't be in the .text section. This is defined as static const
char array, so it should be in one of the data sections. And since we
are using an initializer smaller than the specific size of the array, I
would expect all of the unitialized bits to be 0. But, the proof is in
the pudding. A quick compile and check show us:
Contents of section .rodata:
...
01e0 69576172 70506f72 744d6170 70657255 iWarpPortMapperU
01f0 73657200 00000000 00000000 00000000 ser.............
Yep, just right. It created a 32byte ro element, initialized it to 0,
then put our text in it. This is exactly what will get copied in the nl
message and is precisely what we want.
Applied, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: 0E572FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-05-12 17:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-08 21:36 [PATCH] RDMA/core: Fix for parsing netlink string attribute Tatyana Nikolova
2015-05-08 21:53 ` Jason Gunthorpe
2015-05-12 17:14 ` Doug Ledford [this message]
[not found] ` <1431450866.43876.65.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-05-12 17:50 ` Jason Gunthorpe
[not found] ` <20150512175033.GA15891-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-05-12 20:00 ` Doug Ledford
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=1431450866.43876.65.camel@redhat.com \
--to=dledford@redhat.com \
--cc=Tatyana.E.Nikolova@intel.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=john.s.lacombe@intel.com \
--cc=linux-rdma@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=swise@opengridcomputing.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox