Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 9月, 2014 1 次提交
  3. 09 9月, 2014 2 次提交
  5. 17 7月, 2014 1 次提交
  7. 10 7月, 2014 2 次提交
  9. 01 7月, 2014 1 次提交
  11. 19 6月, 2014 1 次提交
    • M
      usb: gadget: f_fs: fix NULL pointer dereference when there are no strings · f0688c8b
      由 Michal Nazarewicz 提交于 
      If the descriptors do not need any strings and user space sends empty
set of strings, the ffs->stringtabs field remains NULL.  Thus
*ffs->stringtabs in functionfs_bind leads to a NULL pointer
dereferenece.

The bug was introduced by commit [fd7c9a00: “use usb_string_ids_n()”].

While at it, remove double initialisation of lang local variable in
that function.

ffs->strings_count does not need to be checked in any way since in
the above scenario it will remain zero and usb_string_ids_n() is
a no-operation when colled with 0 argument.

Cc: <stable@vger.kernel.org>  # v2.6.36+
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      f0688c8b
  13. 14 5月, 2014 1 次提交
  15. 22 4月, 2014 1 次提交
  17. 16 4月, 2014 1 次提交
    • C
      usb: gadget: ffs: race between ffs_epfile_io() and ffs_func_eps_disable() · 97839ca4
      由 Chao Bi 提交于 
      ffs_epfile_io() is called from userspace, while ffs_func_eps_disable() might be
called from USB disconnect interrupt, the two functions would run in parallel
but they are not well protected, that epfile->ep would be removed by
ffs_func_eps_disable() during ffs_epfile_io() is referring this pointer, then
it leads to kernel PANIC.

The scenario is as below:

Thread 1                                 Thread 2
   |                                        |
SyS_read                             dwc3_gadget_disconnect_interrupt
   |                                        |
ffs_epfile_read                         reset_config
   |                                        |
ffs_epfile_io                       ffs_func_eps_disable
   |                                        |
 -----                      usb_ep_disable():  epfile->ep->ep->desc = NULL
   |                                        |
usb_ep_align_maybe():                     -----
it refers ep->desc->wMaxPacketSize        -----
Signed-off-by: NChao Bi <chao.bi@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      97839ca4
  19. 18 3月, 2014 1 次提交
  21. 08 3月, 2014 1 次提交
  23. 06 3月, 2014 2 次提交
  25. 20 2月, 2014 1 次提交
    • A
      usb: gadget: fix NULL pointer dereference · f0f42204
      由 Andrzej Pietrasiewicz 提交于 
      Fix possible NULL pointer dereference introduced in
commit 219580e6 (usb: f_fs: check quirk to pad epout
buf size when not aligned to maxpacketsize)

In cases we do wait with:

wait_event_interruptible(epfile->wait, (ep = epfile->ep));

for endpoint to be enabled, functionfs_bind() has not been called yet
and epfile->ffs->gadget is still NULL and the automatic variable 'gadget'
has been initialized with NULL at the point of its definition.
Later on it is used as a parameter to:

usb_ep_align_maybe(gadget, ep->ep, len)

which in turn dereferences it.

This patch fixes it by moving the actual assignment to the local 'gadget'
variable after the potential waiting has completed.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      f0f42204
  27. 19 2月, 2014 9 次提交
  29. 13 12月, 2013 7 次提交
  31. 10 12月, 2013 2 次提交
  33. 26 11月, 2013 1 次提交
  35. 15 11月, 2013 1 次提交
  37. 01 10月, 2013 1 次提交
  39. 27 9月, 2013 1 次提交
    • A
      USB: Fix breakage in ffs_fs_mount() · 2606b28a
      由 Al Viro 提交于 
      	There's a bunch of failure exits in ffs_fs_mount() with
seriously broken recovery logics.  Most of that appears to stem
from misunderstanding of the ->kill_sb() semantics; unlike
->put_super() it is called for *all* superblocks of given type,
no matter how (in)complete the setup had been.  ->put_super()
is called only if ->s_root is not NULL; any failure prior to
setting ->s_root will have the call of ->put_super() skipped.
->kill_sb(), OTOH, awaits every superblock that has come from
sget().

Current behaviour of ffs_fs_mount():

We have struct ffs_sb_fill_data data on stack there.  We do
	ffs_dev = functionfs_acquire_dev_callback(dev_name);
and store that in data.private_data.  Then we call mount_nodev(),
passing it ffs_sb_fill() as a callback.  That will either fail
outright, or manage to call ffs_sb_fill().  There we allocate an
instance of struct ffs_data, slap the value of ffs_dev (picked
from data.private_data) into ffs->private_data and overwrite
data.private_data by storing ffs into an overlapping member
(data.ffs_data).  Then we store ffs into sb->s_fs_info and attempt
to set the rest of the things up (root inode, root dentry, then
create /ep0 there).  Any of those might fail.  Should that
happen, we get ffs_fs_kill_sb() called before mount_nodev()
returns.  If mount_nodev() fails for any reason whatsoever,
we proceed to
	functionfs_release_dev_callback(data.ffs_data);

That's broken in a lot of ways.  Suppose the thing has failed in
allocation of e.g. root inode or dentry.  We have
	functionfs_release_dev_callback(ffs);
	ffs_data_put(ffs);
done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by
	functionfs_release_dev_callback(ffs);
from ffs_fs_mount() (via data.ffs_data).  Note that the second
functionfs_release_dev_callback() has every chance to be done to freed memory.

Suppose we fail *before* root inode allocation.  What happens then?
ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all,
or it doesn't have a pointer to ffs stored in sb->s_fs_info).  And
	functionfs_release_dev_callback(data.ffs_data);
is called by ffs_fs_mount(), but here we are in nasal daemon country - we
are reading from a member of union we'd never stored into.  In practice,
we'll get what we used to store into the overlapping field, i.e. ffs_dev.
And then we get screwed, since we treat it (struct gfs_ffs_obj * in
disguise, returned by functionfs_acquire_dev_callback()) as struct
ffs_data *, pick what would've been ffs_data ->private_data from it
(*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data
is much bigger) and poke in whatever it points to.

FWIW, there's a minor leak on top of all that in case if ffs_sb_fill()
fails on kstrdup() - ffs is obviously forgotten.

The thing is, there is no point in playing all those games with union.
Just allocate and initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data.  And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Cc: stable <stable@vger.kernel.org> # 3.3+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2606b28a
  41. 28 8月, 2013 1 次提交
  43. 10 4月, 2013 1 次提交