1. 10 7月, 2014 2 次提交
  2. 01 7月, 2014 1 次提交
  3. 14 5月, 2014 1 次提交
  4. 22 4月, 2014 1 次提交
  5. 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
  6. 18 3月, 2014 1 次提交
  7. 08 3月, 2014 1 次提交
  8. 06 3月, 2014 2 次提交
  9. 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
  10. 19 2月, 2014 9 次提交
  11. 13 12月, 2013 7 次提交
  12. 10 12月, 2013 2 次提交
  13. 26 11月, 2013 1 次提交
  14. 15 11月, 2013 1 次提交
  15. 01 10月, 2013 1 次提交
  16. 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
  17. 28 8月, 2013 1 次提交
  18. 10 4月, 2013 1 次提交
  19. 04 3月, 2013 1 次提交
    • E
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman 提交于
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: NSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reported-by: NKees Cook <keescook@google.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  20. 18 1月, 2013 1 次提交
  21. 10 1月, 2013 1 次提交
  22. 31 10月, 2012 1 次提交
    • S
      usb: gadget: always update HS/SS descriptors and create a copy of them · 10287bae
      Sebastian Andrzej Siewior 提交于
      HS and SS descriptors are staticaly created. They are updated during the
      bind process with the endpoint address, string id or interface numbers.
      
      After that, the descriptor chain is linked to struct usb_function which
      is used by composite in order to serve the GET_DESCRIPTOR requests,
      number of available configs and so on.
      
      There is no need to assign the HS descriptor only if the UDC supports
      HS speed because composite won't report those to the host if HS support
      has not been reached. The same reasoning is valid for SS.
      
      This patch makes sure each function updates HS/SS descriptors
      unconditionally and uses the newly introduced helper function to create a
      copy the descriptors for the speed which is supported by the UDC.
      
      While at that, also rename f->descriptors to f->fs_descriptors in order
      to make it more explicit what that means.
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      10287bae
  23. 27 9月, 2012 1 次提交