From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jian Liu/Gmail <ljian236@gmail.com>
Cc: linux-usb@vger.kernel.org, zhiyunq@cs.ucr.edu, csong@cs.ucr.edu,
yiqiuping@gmail.com, teroincn@163.com
Subject: usb-serial: fix mos_parport refcount imbalance on error path
Date: Wed, 20 Mar 2019 10:05:48 +0100 [thread overview]
Message-ID: <20190320090548.GA27032@kroah.com> (raw)
On Wed, Mar 20, 2019 at 04:59:02PM +0800, Jian Liu/Gmail wrote:
> Hi all,
>
> We might find a security issue in function
> 'write_parport_reg_nonbloc'(for source codes, please refer to
> https://github.com/torvalds/linux/blob/master/drivers/usb/serial/mos7720.c),
> which is logically an unbalanced reference count vulnerability.
>
> Let us check ref_count 'mos_parport->ref_count' of kernel object
> 'mos_parport' in the function. In 'Line 369:
> kref_get(&mos_parport->ref_count)' and 'Line 370:
> urbtrack->mos_parport = mos_parport', the ref_count has been increased
> because of a new variable 'urbtrack->mos_parport' pointing to
> 'mos_parport', that make sense to balance ref_count. However, at 'Line
> 373 and Line 379: kfree(urbtrack)', variable 'urbtrack' has been freed
> before a return, which will make 'urbtrack->mos_parport' freed, too.
> But, a decreasing of 'mos_parport->ref_count' is missing in the
> current kernel version, which will bring an unbalanced reference
> count.
>
> We have wrote a patch showed in Lin's email. The idea is simple. We
> added a calling of 'kref_put(&mos_parport->ref_count,
> destroy_mos_parport)' below Line 373 and Line 379. Currently, we are
> not sure if this is really a vulnerability. If you are familiar with
> codes, please help to verify it.
Yes, this is a bugfix, but not really a "vulnerability" as it is almost
impossible to keep hitting a memory allocation failure enough times to
cause any problems here.
The most that can happen is that the reference really is not dropped,
and memory leaks. Not a big deal, if memory is failing to be allocated,
your system has bigger issues at the moment :)
So it's just a nice bugfix, for a failure mode that is pretty much
impossible to ever hit in the "wild".
thanks,
greg k-h
next reply other threads:[~2019-03-20 9:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 9:05 Greg Kroah-Hartman [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-03-20 9:04 usb-serial: fix mos_parport refcount imbalance on error path Johan Hovold
2019-03-20 8:59 Jian Liu/Gmail
2019-03-20 2:29 Lin Yi
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=20190320090548.GA27032@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=csong@cs.ucr.edu \
--cc=linux-usb@vger.kernel.org \
--cc=ljian236@gmail.com \
--cc=teroincn@163.com \
--cc=yiqiuping@gmail.com \
--cc=zhiyunq@cs.ucr.edu \
/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 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.