1. 23 9月, 2019 9 次提交
  2. 18 9月, 2019 3 次提交
  3. 05 9月, 2019 2 次提交
    • A
      HID: prodikeys: Fix general protection fault during probe · 98375b86
      Alan Stern 提交于
      The syzbot fuzzer provoked a general protection fault in the
      hid-prodikeys driver:
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc5+ #28
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Workqueue: usb_hub_wq hub_event
      RIP: 0010:pcmidi_submit_output_report drivers/hid/hid-prodikeys.c:300  [inline]
      RIP: 0010:pcmidi_set_operational drivers/hid/hid-prodikeys.c:558 [inline]
      RIP: 0010:pcmidi_snd_initialise drivers/hid/hid-prodikeys.c:686 [inline]
      RIP: 0010:pk_probe+0xb51/0xfd0 drivers/hid/hid-prodikeys.c:836
      Code: 0f 85 50 04 00 00 48 8b 04 24 4c 89 7d 10 48 8b 58 08 e8 b2 53 e4 fc
      48 8b 54 24 20 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f
      85 13 04 00 00 48 ba 00 00 00 00 00 fc ff df 49 8b
      
      The problem is caused by the fact that pcmidi_get_output_report() will
      return an error if the HID device doesn't provide the right sort of
      output report, but pcmidi_set_operational() doesn't bother to check
      the return code and assumes the function call always succeeds.
      
      This patch adds the missing check and aborts the probe operation if
      necessary.
      
      Reported-and-tested-by: syzbot+1088533649dafa1c9004@syzkaller.appspotmail.com
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      98375b86
    • R
      HID: sony: Fix memory corruption issue on cleanup. · 2bcdacb7
      Roderick Colenbrander 提交于
      The sony driver is not properly cleaning up from potential failures in
      sony_input_configured. Currently it calls hid_hw_stop, while hid_connect
      is still running. This is not a good idea, instead hid_hw_stop should
      be moved to sony_probe. Similar changes were recently made to Logitech
      drivers, which were also doing improper cleanup.
      Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com>
      CC: stable@vger.kernel.org
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      2bcdacb7
  4. 04 9月, 2019 2 次提交
  5. 03 9月, 2019 2 次提交
  6. 26 8月, 2019 1 次提交
    • H
      HID: logitech-dj: Fix crash when initial logi_dj_recv_query_paired_devices fails · 8ccff284
      Hans de Goede 提交于
      Before this commit dj_probe would exit with an error if the initial
      logi_dj_recv_query_paired_devices fails. The initial call may fail
      when the receiver is connected through a kvm and the focus is away.
      
      When the call fails this causes 2 problems:
      
      1) dj_probe calls logi_dj_recv_query_paired_devices after calling
      hid_device_io_start() so a HID report may have been received in between
      and our delayedwork_callback may be running. It seems that the initial
      logi_dj_recv_query_paired_devices failure happening with some KVMs triggers
      this exact scenario, causing the work-queue to run on free-ed memory,
      leading to:
      
       BUG: unable to handle page fault for address: 0000000000001e88
       #PF: supervisor read access in kernel mode
       #PF: error_code(0x0000) - not-present page
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 3 PID: 257 Comm: kworker/3:3 Tainted: G           OE     5.3.0-rc5+ #100
       Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B150M Pro4S/D3, BIOS P7.10 12/06/2016
       Workqueue: events 0xffffffffc02ba200
       RIP: 0010:0xffffffffc02ba1bd
       Code: e8 e8 13 00 d8 48 89 c5 48 85 c0 74 4c 48 8b 7b 10 48 89 ea b9 07 00 00 00 41 b9 09 00 00 00 41 b8 01 00 00 00 be 10 00 00 00 <48> 8b 87 88 1e 00 00 48 8b 40 40 e8 b3 6b b4 d8 48 89 ef 41 89 c4
       RSP: 0018:ffffb760c046bdb8 EFLAGS: 00010286
       RAX: ffff935038ea4550 RBX: ffff935046778000 RCX: 0000000000000007
       RDX: ffff935038ea4550 RSI: 0000000000000010 RDI: 0000000000000000
       RBP: ffff935038ea4550 R08: 0000000000000001 R09: 0000000000000009
       R10: 000000000000e011 R11: 0000000000000001 R12: ffff9350467780e8
       R13: ffff935046778000 R14: 0000000000000000 R15: ffff935046778070
       FS:  0000000000000000(0000) GS:ffff935054e00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000001e88 CR3: 000000075a612002 CR4: 00000000003606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        0xffffffffc02ba2f7
        ? process_one_work+0x1b1/0x560
        process_one_work+0x234/0x560
        worker_thread+0x50/0x3b0
        kthread+0x10a/0x140
        ? process_one_work+0x560/0x560
        ? kthread_park+0x80/0x80
        ret_from_fork+0x3a/0x50
       Modules linked in: vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep vfat fat btusb btrtl btbcm btintel bluetooth intel_rapl_msr ecdh_generic rfkill ecc snd_usb_audio snd_usbmidi_lib intel_rapl_common snd_rawmidi mc x86_pkg_temp_thermal intel_powerclamp coretemp iTCO_wdt iTCO_vendor_support mei_wdt mei_hdcp ppdev kvm_intel kvm irqbypass crct10dif_pclmul crc32_generic crc32_pclmul snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ghash_clmulni_intel intel_cstate snd_hda_intel snd_hda_codec intel_uncore snd_hda_core snd_hwdep intel_rapl_perf snd_seq snd_seq_device snd_pcm snd_timer intel_wmi_thunderbolt snd e1000e soundcore mxm_wmi i2c_i801 bfq mei_me mei intel_pch_thermal parport_pc parport acpi_pad binfmt_misc hid_lg_g15(E) hid_logitech_dj(E) i915 crc32c_intel i2c_algo_bit drm_kms_helper nvme nvme_core drm wmi video uas usb_storage i2c_dev
       CR2: 0000000000001e88
       ---[ end trace 1d3f8afdcfcbd842 ]---
      
      2) Even if we were to fix 1. by making sure the work is stopped before
      failing probe, failing probe is the wrong thing to do, we have
      logi_dj_recv_queue_unknown_work to deal with the initial
      logi_dj_recv_query_paired_devices failure.
      
      Rather then error-ing out of the probe, causing the receiver to not work at
      all we should rely on this, so that the attached devices will get properly
      enumerated once the KVM focus is switched back.
      
      Cc: stable@vger.kernel.org
      Fixes: 74808f91 ("HID: logitech-dj: add support for non unifying receivers")
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      8ccff284
  7. 23 8月, 2019 3 次提交
  8. 22 8月, 2019 5 次提交
    • B
      HID: multitouch: add support for the Smart Tech panel · 69ecd44d
      Benjamin Tissoires 提交于
      This panel is not very friendly to us:
      it exposes multiple multitouch collections, some of them being of
      logical application stylus.
      
      Usually, a device has only one report per application, and that is
      what I assumed in commit 8dfe14b3 ("HID: multitouch: ditch mt_report_id")
      
      To avoid breaking all working device, add a new class and a new quirk
      for that situation.
      Reported-and-tested-by: NMatthias Fend <Matthias.Fend@wolfvision.net>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      69ecd44d
    • B
      HID: multitouch: do not filter mice nodes · c23e2043
      Benjamin Tissoires 提交于
      It was a good idea at the time to not create a mouse node for the
      multitouch touchscreens, but:
      - touchscreens following the Win 8 protocol should not have this
        disturbing mouse node anymore, or if they have, it should be
        used for something else (like a joystick attached to the screen)
      - touchpads have it, and they should not use it unless there is a bug,
        but when the laptop has a trackstick, the data are reported through this
        mouse node.
      
      So instead of whitelisting all of the devices that have a need for the
      mouse node, just export it.
      hid-input.c will append a suffix to it ('Mouse'), so users will eventually
      see if something goes wrong.
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      c23e2043
    • B
      HID: do not call hid_set_drvdata(hdev, NULL) in drivers · 87fcb6a6
      Benjamin Tissoires 提交于
      This is a common pattern in the HID drivers to reset the drvdata. Some
      do it properly, some do it only in case of failure.
      
      But, this is actually already handled by driver core, so there is no need
      to do it manually.
      
      [for hid-sensor-hub.c]
      Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [For hid-picolcd_core.c]
      Acked-by: NBruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      87fcb6a6
    • A
      HID: logitech: Fix general protection fault caused by Logitech driver · 5f924277
      Alan Stern 提交于
      The syzbot fuzzer found a general protection fault in the HID subsystem:
      
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      CPU: 0 PID: 3715 Comm: syz-executor.3 Not tainted 5.2.0-rc6+ #15
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__pm_runtime_resume+0x49/0x180 drivers/base/power/runtime.c:1069
      Code: ed 74 d5 fe 45 85 ed 0f 85 9a 00 00 00 e8 6f 73 d5 fe 48 8d bd c1 02
      00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48
      89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 fe 00 00 00
      RSP: 0018:ffff8881d99d78e0 EFLAGS: 00010202
      RAX: dffffc0000000000 RBX: 0000000000000020 RCX: ffffc90003f3f000
      RDX: 0000000416d8686d RSI: ffffffff82676841 RDI: 00000020b6c3436a
      RBP: 00000020b6c340a9 R08: ffff8881c6d64800 R09: fffffbfff0e84c25
      R10: ffff8881d99d7940 R11: ffffffff87426127 R12: 0000000000000004
      R13: 0000000000000000 R14: ffff8881d9b94000 R15: ffffffff897f9048
      FS:  00007f047f542700(0000) GS:ffff8881db200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b30f21000 CR3: 00000001ca032000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        pm_runtime_get_sync include/linux/pm_runtime.h:226 [inline]
        usb_autopm_get_interface+0x1b/0x50 drivers/usb/core/driver.c:1707
        usbhid_power+0x7c/0xe0 drivers/hid/usbhid/hid-core.c:1234
        hid_hw_power include/linux/hid.h:1038 [inline]
        hidraw_open+0x20d/0x740 drivers/hid/hidraw.c:282
        chrdev_open+0x219/0x5c0 fs/char_dev.c:413
        do_dentry_open+0x497/0x1040 fs/open.c:778
        do_last fs/namei.c:3416 [inline]
        path_openat+0x1430/0x3ff0 fs/namei.c:3533
        do_filp_open+0x1a1/0x280 fs/namei.c:3563
        do_sys_open+0x3c0/0x580 fs/open.c:1070
        do_syscall_64+0xb7/0x560 arch/x86/entry/common.c:301
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      It turns out the fault was caused by a bug in the HID Logitech driver,
      which violates the requirement that every pathway calling
      hid_hw_start() must also call hid_hw_stop().  This patch fixes the bug
      by making sure the requirement is met.
      
      Reported-and-tested-by: syzbot+3cbe5cd105d2ad56a1df@syzkaller.appspotmail.com
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      5f924277
    • A
      HID: hidraw: Fix invalid read in hidraw_ioctl · 416dacb8
      Alan Stern 提交于
      The syzbot fuzzer has reported a pair of problems in the
      hidraw_ioctl() function: slab-out-of-bounds read and use-after-free
      read.  An example of the first:
      
      BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
      Read of size 1 at addr ffff8881c8035f38 by task syz-executor.4/2833
      
      CPU: 1 PID: 2833 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #1
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      Call Trace:
        __dump_stack lib/dump_stack.c:77 [inline]
        dump_stack+0xca/0x13e lib/dump_stack.c:113
        print_address_description+0x6a/0x32c mm/kasan/report.c:351
        __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482
        kasan_report+0xe/0x12 mm/kasan/common.c:612
        strlen+0x79/0x90 lib/string.c:525
        strlen include/linux/string.h:281 [inline]
        hidraw_ioctl+0x245/0xae0 drivers/hid/hidraw.c:446
        vfs_ioctl fs/ioctl.c:46 [inline]
        file_ioctl fs/ioctl.c:509 [inline]
        do_vfs_ioctl+0xd2d/0x1330 fs/ioctl.c:696
        ksys_ioctl+0x9b/0xc0 fs/ioctl.c:713
        __do_sys_ioctl fs/ioctl.c:720 [inline]
        __se_sys_ioctl fs/ioctl.c:718 [inline]
        __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718
        do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x459829
      Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
      48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
      ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f7a68f6dc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000459829
      RDX: 0000000000000000 RSI: 0000000080404805 RDI: 0000000000000004
      RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f7a68f6e6d4
      R13: 00000000004c21de R14: 00000000004d5620 R15: 00000000ffffffff
      
      The two problems have the same cause: hidraw_ioctl() fails to test
      whether the device has been removed.  This patch adds the missing test.
      
      Reported-and-tested-by: syzbot+5a6c4ec678a0c6ee84ba@syzkaller.appspotmail.com
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      416dacb8
  9. 21 8月, 2019 1 次提交
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid · 15d90b24
      Linus Torvalds 提交于
      Pull HID fixes from Jiri Kosina:
      
       - a few regression fixes for wacom driver (including fix for my earlier
         mismerge) from Aaron Armstrong Skomra and Jason Gerecke
      
       - revert of a few Logitech device ID additions which turn out to not
         work perfectly with the hidpp driver at the moment; proper support is
         now scheduled for 5.4. Fixes from Benjamin Tissoires
      
       - scheduling-in-atomic fix for cp2112 driver, from Benjamin Tissoires
      
       - new device ID to intel-ish, from Even Xu
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid:
        HID: wacom: correct misreported EKR ring values
        HID: cp2112: prevent sleeping function called from invalid context
        HID: intel-ish-hid: ipc: add EHL device id
        HID: wacom: Correct distance scale for 2nd-gen Intuos devices
        HID: logitech-hidpp: remove support for the G700 over USB
        Revert "HID: logitech-hidpp: add USB PID for a few more supported mice"
        HID: wacom: add back changes dropped in merge commit
      15d90b24
  10. 20 8月, 2019 5 次提交
    • A
      HID: wacom: correct misreported EKR ring values · fcf887e7
      Aaron Armstrong Skomra 提交于
      The EKR ring claims a range of 0 to 71 but actually reports
      values 1 to 72. The ring is used in relative mode so this
      change should not affect users.
      Signed-off-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Fixes: 72b236d6 ("HID: wacom: Add support for Express Key Remote.")
      Cc: <stable@vger.kernel.org> # v4.3+
      Reviewed-by: NPing Cheng <ping.cheng@wacom.com>
      Reviewed-by: NJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      fcf887e7
    • L
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 5f97cbe2
      Linus Torvalds 提交于
      Pull clk fixes from Stephen Boyd:
       "A couple fixes to the core framework logic that finds clk parents, a
        handful of samsung clk driver fixes for audio and display clks, and a
        small fix for the Stratix10 SoC driver that was checking the wrong
        register for validity"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: Fix potential NULL dereference in clk_fetch_parent_index()
        clk: Fix falling back to legacy parent string matching
        clk: socfpga: stratix10: fix rate caclulationg for cnt_clks
        clk: samsung: exynos542x: Move MSCL subsystem clocks to its sub-CMU
        clk: samsung: exynos5800: Move MAU subsystem clocks to MAU sub-CMU
        clk: samsung: Change signature of exynos5_subcmus_init() function
      5f97cbe2
    • L
      Merge branch 'siginfo-linus' of... · 287c55ed
      Linus Torvalds 提交于
      Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
      
      Pull kernel thread signal handling fix from Eric Biederman:
       "I overlooked the fact that kernel threads are created with all signals
        set to SIG_IGN, and accidentally caused a regression in cifs and drbd
        when replacing force_sig with send_sig.
      
        This is my fix for that regression. I add a new function
        allow_kernel_signal which allows kernel threads to receive signals
        sent from the kernel, but continues to ignore all signals sent from
        userspace. This ensures the user space interface for cifs and drbd
        remain the same.
      
        These kernel threads depend on blocking networking calls which block
        until something is received or a signal is pending. Making receiving
        of signals somewhat necessary for these kernel threads.
      
        Perhaps someday we can cleanup those interfaces and remove
        allow_kernel_signal. If not allow_kernel_signal is pretty trivial and
        clearly documents what is going on so I don't think we will mind
        carrying it"
      
      * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        signal: Allow cifs and drbd to receive their terminating signals
      287c55ed
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 06821504
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
        1) Fix jmp to 1st instruction in x64 JIT, from Alexei Starovoitov.
      
        2) Severl kTLS fixes in mlx5 driver, from Tariq Toukan.
      
        3) Fix severe performance regression due to lack of SKB coalescing of
           fragments during local delivery, from Guillaume Nault.
      
        4) Error path memory leak in sch_taprio, from Ivan Khoronzhuk.
      
        5) Fix batched events in skbedit packet action, from Roman Mashak.
      
        6) Propagate VLAN TX offload to hw_enc_features in bond and team
           drivers, from Yue Haibing.
      
        7) RXRPC local endpoint refcounting fix and read after free in
           rxrpc_queue_local(), from David Howells.
      
        8) Fix endian bug in ibmveth multicast list handling, from Thomas
           Falcon.
      
        9) Oops, make nlmsg_parse() wrap around the correct function,
           __nlmsg_parse not __nla_parse(). Fix from David Ahern.
      
       10) Memleak in sctp_scend_reset_streams(), fro Zheng Bin.
      
       11) Fix memory leak in cxgb4, from Wenwen Wang.
      
       12) Yet another race in AF_PACKET, from Eric Dumazet.
      
       13) Fix false detection of retransmit failures in tipc, from Tuong
           Lien.
      
       14) Use after free in ravb_tstamp_skb, from Tho Vu.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (101 commits)
        ravb: Fix use-after-free ravb_tstamp_skb
        netfilter: nf_tables: map basechain priority to hardware priority
        net: sched: use major priority number as hardware priority
        wimax/i2400m: fix a memory leak bug
        net: cavium: fix driver name
        ibmvnic: Unmap DMA address of TX descriptor buffers after use
        bnxt_en: Fix to include flow direction in L2 key
        bnxt_en: Use correct src_fid to determine direction of the flow
        bnxt_en: Suppress HWRM errors for HWRM_NVM_GET_VARIABLE command
        bnxt_en: Fix handling FRAG_ERR when NVM_INSTALL_UPDATE cmd fails
        bnxt_en: Improve RX doorbell sequence.
        bnxt_en: Fix VNIC clearing logic for 57500 chips.
        net: kalmia: fix memory leaks
        cx82310_eth: fix a memory leak bug
        bnx2x: Fix VF's VLAN reconfiguration in reload.
        Bluetooth: Add debug setting for changing minimum encryption key size
        tipc: fix false detection of retransmit failures
        lan78xx: Fix memory leaks
        MAINTAINERS: r8169: Update path to the driver
        MAINTAINERS: PHY LIBRARY: Update files in the record
        ...
      06821504
    • D
      keys: Fix description size · 555df336
      David Howells 提交于
      The maximum key description size is 4095.  Commit f771fde8 ("keys:
      Simplify key description management") inadvertantly reduced that to 255
      and made sizes between 256 and 4095 work weirdly, and any size whereby
      size & 255 == 0 would cause an assertion in __key_link_begin() at the
      following line:
      
      	BUG_ON(index_key->desc_len == 0);
      
      This can be fixed by simply increasing the size of desc_len in struct
      keyring_index_key to a u16.
      
      Note the argument length test in keyutils only checked empty
      descriptions and descriptions with a size around the limit (ie.  4095)
      and not for all the values in between, so it missed this.  This has been
      addressed and
      
      	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/commit/?id=066bf56807c26cd3045a25f355b34c1d8a20a5aa
      
      now exhaustively tests all possible lengths of type, description and
      payload and then some.
      
      The assertion failure looks something like:
      
       kernel BUG at security/keys/keyring.c:1245!
       ...
       RIP: 0010:__key_link_begin+0x88/0xa0
       ...
       Call Trace:
        key_create_or_update+0x211/0x4b0
        __x64_sys_add_key+0x101/0x200
        do_syscall_64+0x5b/0x1e0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      It can be triggered by:
      
      	keyctl add user "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" a @s
      
      Fixes: f771fde8 ("keys: Simplify key description management")
      Reported-by: Nkernel test robot <rong.a.chen@intel.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      555df336
  11. 19 8月, 2019 7 次提交