1. 07 10月, 2020 1 次提交
  2. 01 10月, 2020 7 次提交
  3. 30 9月, 2020 14 次提交
  4. 29 9月, 2020 2 次提交
  5. 28 9月, 2020 4 次提交
  6. 27 9月, 2020 2 次提交
    • N
      i2c: cpm: Fix i2c_ram structure · a2bd970a
      Nicolas VINCENT 提交于
      the i2c_ram structure is missing the sdmatmp field mentionned in
      datasheet for MPC8272 at paragraph 36.5. With this field missing, the
      hardware would write past the allocated memory done through
      cpm_muram_alloc for the i2c_ram structure and land in memory allocated
      for the buffers descriptors corrupting the cbd_bufaddr field. Since this
      field is only set during setup(), the first i2c transaction would work
      and the following would send data read from an arbitrary memory
      location.
      
      Fixes: 61045dbe ("i2c: Add support for I2C bus on Freescale CPM1/CPM2 controllers")
      Signed-off-by: NNicolas VINCENT <nicolas.vincent@vossloh.com>
      Acked-by: NJochen Friedrich <jochen@scram.de>
      Acked-by: NChristophe Leroy <christophe.leroy@csgroup.eu>
      Signed-off-by: NWolfram Sang <wsa@kernel.org>
      a2bd970a
    • L
      mm: don't rely on system state to detect hot-plug operations · f85086f9
      Laurent Dufour 提交于
      In register_mem_sect_under_node() the system_state's value is checked to
      detect whether the call is made during boot time or during an hot-plug
      operation.  Unfortunately, that check against SYSTEM_BOOTING is wrong
      because regular memory is registered at SYSTEM_SCHEDULING state.  In
      addition, memory hot-plug operation can be triggered at this system
      state by the ACPI [1].  So checking against the system state is not
      enough.
      
      The consequence is that on system with interleaved node's ranges like this:
      
       Early memory node ranges
         node   1: [mem 0x0000000000000000-0x000000011fffffff]
         node   2: [mem 0x0000000120000000-0x000000014fffffff]
         node   1: [mem 0x0000000150000000-0x00000001ffffffff]
         node   0: [mem 0x0000000200000000-0x000000048fffffff]
         node   2: [mem 0x0000000490000000-0x00000007ffffffff]
      
      This can be seen on PowerPC LPAR after multiple memory hot-plug and
      hot-unplug operations are done.  At the next reboot the node's memory
      ranges can be interleaved and since the call to link_mem_sections() is
      made in topology_init() while the system is in the SYSTEM_SCHEDULING
      state, the node's id is not checked, and the sections registered to
      multiple nodes:
      
        $ ls -l /sys/devices/system/memory/memory21/node*
        total 0
        lrwxrwxrwx 1 root root     0 Aug 24 05:27 node1 -> ../../node/node1
        lrwxrwxrwx 1 root root     0 Aug 24 05:27 node2 -> ../../node/node2
      
      In that case, the system is able to boot but if later one of theses
      memory blocks is hot-unplugged and then hot-plugged, the sysfs
      inconsistency is detected and this is triggering a BUG_ON():
      
        kernel BUG at /Users/laurent/src/linux-ppc/mm/memory_hotplug.c:1084!
        Oops: Exception in kernel mode, sig: 5 [#1]
        LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: rpadlpar_io rpaphp pseries_rng rng_core vmx_crypto gf128mul binfmt_misc ip_tables x_tables xfs libcrc32c crc32c_vpmsum autofs4
        CPU: 8 PID: 10256 Comm: drmgr Not tainted 5.9.0-rc1+ #25
        Call Trace:
          add_memory_resource+0x23c/0x340 (unreliable)
          __add_memory+0x5c/0xf0
          dlpar_add_lmb+0x1b4/0x500
          dlpar_memory+0x1f8/0xb80
          handle_dlpar_errorlog+0xc0/0x190
          dlpar_store+0x198/0x4a0
          kobj_attr_store+0x30/0x50
          sysfs_kf_write+0x64/0x90
          kernfs_fop_write+0x1b0/0x290
          vfs_write+0xe8/0x290
          ksys_write+0xdc/0x130
          system_call_exception+0x160/0x270
          system_call_common+0xf0/0x27c
      
      This patch addresses the root cause by not relying on the system_state
      value to detect whether the call is due to a hot-plug operation.  An
      extra parameter is added to link_mem_sections() detailing whether the
      operation is due to a hot-plug operation.
      
      [1] According to Oscar Salvador, using this qemu command line, ACPI
      memory hotplug operations are raised at SYSTEM_SCHEDULING state:
      
        $QEMU -enable-kvm -machine pc -smp 4,sockets=4,cores=1,threads=1 -cpu host -monitor pty \
              -m size=$MEM,slots=255,maxmem=4294967296k  \
              -numa node,nodeid=0,cpus=0-3,mem=512 -numa node,nodeid=1,mem=512 \
              -object memory-backend-ram,id=memdimm0,size=134217728 -device pc-dimm,node=0,memdev=memdimm0,id=dimm0,slot=0 \
              -object memory-backend-ram,id=memdimm1,size=134217728 -device pc-dimm,node=0,memdev=memdimm1,id=dimm1,slot=1 \
              -object memory-backend-ram,id=memdimm2,size=134217728 -device pc-dimm,node=0,memdev=memdimm2,id=dimm2,slot=2 \
              -object memory-backend-ram,id=memdimm3,size=134217728 -device pc-dimm,node=0,memdev=memdimm3,id=dimm3,slot=3 \
              -object memory-backend-ram,id=memdimm4,size=134217728 -device pc-dimm,node=1,memdev=memdimm4,id=dimm4,slot=4 \
              -object memory-backend-ram,id=memdimm5,size=134217728 -device pc-dimm,node=1,memdev=memdimm5,id=dimm5,slot=5 \
              -object memory-backend-ram,id=memdimm6,size=134217728 -device pc-dimm,node=1,memdev=memdimm6,id=dimm6,slot=6 \
      
      Fixes: 4fbce633 ("mm/memory_hotplug.c: make register_mem_sect_under_node() a callback of walk_memory_range()")
      Signed-off-by: NLaurent Dufour <ldufour@linux.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: NDavid Hildenbrand <david@redhat.com>
      Reviewed-by: NOscar Salvador <osalvador@suse.de>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Nathan Lynch <nathanl@linux.ibm.com>
      Cc: Scott Cheloha <cheloha@linux.ibm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20200915094143.79181-3-ldufour@linux.ibm.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f85086f9
  7. 25 9月, 2020 6 次提交
    • M
      usbcore/driver: Accommodate usbip · 3fce3960
      M. Vefa Bicakci 提交于
      Commit 88b7381a ("USB: Select better matching USB drivers when
      available") inadvertently broke usbip functionality. The commit in
      question allows USB device drivers to be explicitly matched with
      USB devices via the use of driver-provided identifier tables and
      match functions, which is useful for a specialised device driver
      to be chosen for a device that can also be handled by another,
      more generic, device driver.
      
      Prior, the USB device section of usb_device_match() had an
      unconditional "return 1" statement, which allowed user-space to bind
      USB devices to the usbip_host device driver, if desired. However,
      the aforementioned commit changed the default/fallback return
      value to zero. This breaks device drivers such as usbip_host, so
      this commit restores the legacy behaviour, but only if a device
      driver does not have an id_table and a match() function.
      
      In addition, if usb_device_match is called for a device driver
      and device pair where the device does not match the id_table of the
      device driver in question, then the device driver will be disqualified
      for the device. This allows avoiding the default case of "return 1",
      which prevents undesirable probe() calls to a driver even though
      its id_table did not match the device.
      
      Finally, this commit changes the specialised-driver-to-generic-driver
      transition code so that when a device driver returns -ENODEV, a more
      generic device driver is only considered if the current device driver
      does not have an id_table and a match() function. This ensures that
      "generic" drivers such as usbip_host will not be considered specialised
      device drivers and will not cause the device to be locked in to the
      generic device driver, when a more specialised device driver could be
      tried.
      
      All of these changes restore usbip functionality without regressions,
      ensure that the specialised/generic device driver selection logic works
      as expected with the usb and apple-mfi-fastcharge drivers, and do not
      negatively affect the use of devices provided by dummy_hcd.
      
      Fixes: 88b7381a ("USB: Select better matching USB drivers when available")
      Cc: <stable@vger.kernel.org> # 5.8
      Cc: Bastien Nocera <hadess@hadess.net>
      Cc: Valentina Manea <valentina.manea.m@gmail.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: <syzkaller@googlegroups.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com>
      Link: https://lore.kernel.org/r/20200922110703.720960-5-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3fce3960
    • M
      usbcore/driver: Fix incorrect downcast · 4df30e76
      M. Vefa Bicakci 提交于
      This commit resolves a minor bug in the selection/discovery of more
      specific USB device drivers for devices that are currently bound to
      generic USB device drivers.
      
      The bug is related to the way a candidate USB device driver is
      compared against the generic USB device driver. The code in
      is_dev_usb_generic_driver() assumes that the device driver in question
      is a USB device driver by calling to_usb_device_driver(dev->driver)
      to downcast; however I have observed that this assumption is not always
      true, through code instrumentation.
      
      This commit avoids the incorrect downcast altogether by comparing
      the USB device's driver (i.e., dev->driver) to the generic USB
      device driver directly. This method was suggested by Alan Stern.
      
      This bug was found while investigating Andrey Konovalov's report
      indicating usbip device driver misbehaviour with the recently merged
      generic USB device driver selection feature. The report is linked
      below.
      
      Fixes: d5643d22 ("USB: Fix device driver race")
      Cc: <stable@vger.kernel.org> # 5.8
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Bastien Nocera <hadess@hadess.net>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Valentina Manea <valentina.manea.m@gmail.com>
      Cc: <syzkaller@googlegroups.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com>
      Link: https://lore.kernel.org/r/20200922110703.720960-4-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4df30e76
    • M
      usbcore/driver: Fix specific driver selection · aea850cd
      M. Vefa Bicakci 提交于
      This commit resolves a bug in the selection/discovery of more
      specific USB device drivers for devices that are currently bound to
      generic USB device drivers.
      
      The bug is in the logic that determines whether a device currently
      bound to a generic USB device driver should be re-probed by a
      more specific USB device driver or not. The code in
      __usb_bus_reprobe_drivers() used to have the following lines:
      
        if (usb_device_match_id(udev, new_udriver->id_table) == NULL &&
            (!new_udriver->match || new_udriver->match(udev) != 0))
       		return 0;
      
        ret = device_reprobe(dev);
      
      As the reader will notice, the code checks whether the USB device in
      consideration matches the identifier table (id_table) of a specific
      USB device_driver (new_udriver), followed by a similar check, but this
      time with the USB device driver's match function. However, the match
      function's return value is not checked correctly. When match() returns
      zero, it means that the specific USB device driver is *not* applicable
      to the USB device in question, but the code then goes on to reprobe the
      device with the new USB device driver under consideration. All this to
      say, the logic is inverted.
      
      This bug was found by code inspection and instrumentation while
      investigating the root cause of the issue reported by Andrey Konovalov,
      where usbip took over syzkaller's virtual USB devices in an undesired
      manner. The report is linked below.
      
      Fixes: d5643d22 ("USB: Fix device driver race")
      Cc: <stable@vger.kernel.org> # 5.8
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Bastien Nocera <hadess@hadess.net>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Valentina Manea <valentina.manea.m@gmail.com>
      Cc: <syzkaller@googlegroups.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com>
      Link: https://lore.kernel.org/r/20200922110703.720960-3-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aea850cd
    • M
      Revert "usbip: Implement a match function to fix usbip" · d6407613
      M. Vefa Bicakci 提交于
      This commit reverts commit 7a2f2974 ("usbip: Implement a match
      function to fix usbip").
      
      In summary, commit d5643d22 ("USB: Fix device driver race")
      inadvertently broke usbip functionality, which I resolved in an incorrect
      manner by introducing a match function to usbip, usbip_match(), that
      unconditionally returns true.
      
      However, the usbip_match function, as is, causes usbip to take over
      virtual devices used by syzkaller for USB fuzzing, which is a regression
      reported by Andrey Konovalov.
      
      Furthermore, in conjunction with the fix of another bug, handled by another
      patch titled "usbcore/driver: Fix specific driver selection" in this patch
      set, the usbip_match function causes unexpected USB subsystem behaviour
      when the usbip_host driver is loaded. The unexpected behaviour can be
      qualified as follows:
      - If commit 41160802ab8e ("USB: Simplify USB ID table match") is included
        in the kernel, then all USB devices are bound to the usbip_host
        driver, which appears to the user as if all USB devices were
        disconnected.
      - If the same commit (41160802ab8e) is not in the kernel (as is the case
        with v5.8.10) then all USB devices are re-probed and re-bound to their
        original device drivers, which appears to the user as a disconnection
        and re-connection of USB devices.
      
      Please note that this commit will make usbip non-operational again,
      until yet another patch in this patch set is merged, titled
      "usbcore/driver: Accommodate usbip".
      
      Cc: <stable@vger.kernel.org> # 5.8: 41160802ab8e: USB: Simplify USB ID table match
      Cc: <stable@vger.kernel.org> # 5.8
      Cc: Bastien Nocera <hadess@hadess.net>
      Cc: Valentina Manea <valentina.manea.m@gmail.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: <syzkaller@googlegroups.com>
      Reported-by: NAndrey Konovalov <andreyknvl@google.com>
      Tested-by: NAndrey Konovalov <andreyknvl@google.com>
      Acked-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NM. Vefa Bicakci <m.v.b@runbox.com>
      Link: https://lore.kernel.org/r/20200922110703.720960-2-m.v.b@runbox.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d6407613
    • P
      fbcon: Fix global-out-of-bounds read in fbcon_get_font() · 5af08640
      Peilin Ye 提交于
      fbcon_get_font() is reading out-of-bounds. A malicious user may resize
      `vc->vc_font.height` to a large value, causing fbcon_get_font() to
      read out of `fontdata`.
      
      fbcon_get_font() handles both built-in and user-provided fonts.
      Fortunately, recently we have added FONT_EXTRA_WORDS support for built-in
      fonts, so fix it by adding range checks using FNTSIZE().
      
      This patch depends on patch "fbdev, newport_con: Move FONT_EXTRA_WORDS
      macros into linux/font.h", and patch "Fonts: Support FONT_EXTRA_WORDS
      macros for built-in fonts".
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: syzbot+29d4ed7f3bdedf2aa2fd@syzkaller.appspotmail.com
      Link: https://syzkaller.appspot.com/bug?id=08b8be45afea11888776f897895aef9ad1c3ecfdSigned-off-by: NPeilin Ye <yepeilin.cs@gmail.com>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/b34544687a1a09d6de630659eb7a773f4953238b.1600953813.git.yepeilin.cs@gmail.com
      5af08640
    • P
      fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h · bb0890b4
      Peilin Ye 提交于
      drivers/video/console/newport_con.c is borrowing FONT_EXTRA_WORDS macros
      from drivers/video/fbdev/core/fbcon.h. To keep things simple, move all
      definitions into <linux/font.h>.
      
      Since newport_con now uses four extra words, initialize the fourth word in
      newport_set_font() properly.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NPeilin Ye <yepeilin.cs@gmail.com>
      Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/7fb8bc9b0abc676ada6b7ac0e0bd443499357267.1600953813.git.yepeilin.cs@gmail.com
      bb0890b4
  8. 24 9月, 2020 4 次提交