- 21 Apr, 2016 40 commits
-
-
Michael S. Tsirkin authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 10e7ac22 upstream. Calling return copy_to_user(...) in an ioctl will not do the right thing if there's a pagefault: copy_to_user returns the number of bytes not copied in this case. Fix up watchdog/rc32434_wdt to do return copy_to_user(...)) ? -EFAULT : 0; instead. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Joshua Hunt authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit a1ee1932 upstream. While working on a script to restore all sysctl params before a series of tests I found that writing any value into the /proc/sys/kernel/{nmi_watchdog,soft_watchdog,watchdog,watchdog_thresh} causes them to call proc_watchdog_update(). NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. There doesn't appear to be a reason for doing this work every time a write occurs, so only do it when the values change. Signed-off-by:
Josh Hunt <johunt@akamai.com> Acked-by:
Don Zickus <dzickus@redhat.com> Reviewed-by:
Aaron Tomlin <atomlin@redhat.com> Cc: Ulrich Obergfell <uobergfe@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Luis R. Rodriguez authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit b0f84ac3 upstream. All architectures now need ioremap_uc(), ia64 seems defines this already through its ioremap_nocache() and it already ensures it *only* uses UC. This is needed since v4.3 to complete an allyesconfig compile on ia64, there were others archs that needed this, and this one seems to have fallen through the cracks. Signed-off-by:
Luis R. Rodriguez <mcgrof@kernel.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Acked-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Johannes Weiner authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit b6e6edcf upstream. Setting the original memory.limit_in_bytes hardlimit is subject to a race condition when the desired value is below the current usage. The code tries a few times to first reclaim and then see if the usage has dropped to where we would like it to be, but there is no locking, and the workload is free to continue making new charges up to the old limit. Thus, attempting to shrink a workload relies on pure luck and hope that the workload happens to cooperate. To fix this in the cgroup2 memory.max knob, do it the other way round: set the limit first, then try enforcement. And if reclaim is not able to succeed, trigger OOM kills in the group. Keep going until the new limit is met, we run out of OOM victims and there's only unreclaimable memory left, or the task writing to memory.max is killed. This allows users to shrink groups reliably, and the behavior is consistent with what happens when new charges are attempted in excess of memory.max. Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Vladimir Davydov <vdavydov@virtuozzo.com> Signed-off-by:
-
Johannes Weiner authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 588083bb upstream. When setting memory.high below usage, nothing happens until the next charge comes along, and then it will only reclaim its own charge and not the now potentially huge excess of the new memory.high. This can cause groups to stay in excess of their memory.high indefinitely. To fix that, when shrinking memory.high, kick off a reclaim cycle that goes after the delta. Signed-off-by:
-
Eric Wheeler authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit f8b11260 upstream. When bch_cache_set_alloc() fails to kzalloc the cache_set, the asyncronous closure handling tries to dereference a cache_set that hadn't yet been allocated inside of cache_set_flush() which is called by __cache_set_unregister() during cleanup. This appears to happen only during an OOM condition on bcache_register. Signed-off-by:
Eric Wheeler <bcache@linux.ewheeler.net> Signed-off-by:
-
Eric Wheeler authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 07cc6ef8 upstream. The bch_writeback_thread might BUG_ON in read_dirty() if dc->sb==BDEV_STATE_DIRTY and bch_sectors_dirty_init has not yet completed its related initialization. This patch downs the dc->writeback_lock until after initialization is complete, thus preventing bch_writeback_thread from proceeding prematurely. See this thread: http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3453Signed-off-by:
Marc MERLIN <marc@merlins.org> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Eric Wheeler authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 9b299728 upstream. Fix null pointer dereference by changing register_cache() to return an int instead of being void. This allows it to return -ENOMEM or -ENODEV and enables upper layers to handle the OOM case without NULL pointer issues. See this thread: http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3521 Fixes this error: gargamel:/sys/block/md5/bcache# echo /dev/sdh2 > /sys/fs/bcache/register bcache: register_cache() error opening sdh2: cannot allocate memory BUG: unable to handle kernel NULL pointer dereference at 00000000000009b8 IP: [<ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache] PGD 120dff067 PUD 1119a3067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: veth ip6table_filter ip6_tables (...) CPU: 4 PID: 3371 Comm: kworker/4:3 Not tainted 4.4.2-amd64-i915-volpreempt-20160213bc1 #3 Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013 Workqueue: events cache_set_flush [bcache] task: ffff88020d5dc280 ti: ffff88020b6f8000 task.ti: ffff88020b6f8000 RIP: 0010:[<ffffffffc05a7e8d>] [<ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache] Signed-off-by:
-
Bart Van Assche authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 51093254 upstream. Let the target core check task existence instead of the SRP target driver. Additionally, let the target core check the validity of the task management request instead of the ib_srpt driver. This patch fixes the following kernel crash: BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [<ffffffffa0565f37>] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt] Oops: 0002 [#1] SMP Call Trace: [<ffffffffa05660ce>] srpt_process_completion+0xde/0x570 [ib_srpt] [<ffffffffa056669f>] srpt_compl_thread+0x13f/0x160 [ib_srpt] [<ffffffff8109726f>] kthread+0xcf/0xe0 [<ffffffff81613cfc>] ret_from_fork+0x7c/0xb0 Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Fixes: 3e4f5748 ("ib_srpt: Convert TMR path to target_submit_tmr") Tested-by:
Alex Estrin <alex.estrin@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Bart Van Assche authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 5e4298be upstream. Avoid that discard requests with size => PAGE_SIZE fail with -EIO. Refuse discard requests if the discard size is not a multiple of the page size. Fixes: 2dbe5495 ("brd: Refuse improperly aligned discard requests") Signed-off-by:
Jan Kara <jack@suse.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Robert Elliot <elliott@hp.com> Signed-off-by:
-
OGAWA Hirofumi authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit c0a2ad9b upstream. On umount path, jbd2_journal_destroy() writes latest transaction ID (->j_tail_sequence) to be used at next mount. The bug is that ->j_tail_sequence is not holding latest transaction ID in some cases. So, at next mount, there is chance to conflict with remaining (not overwritten yet) transactions. mount (id=10) write transaction (id=11) write transaction (id=12) umount (id=10) <= the bug doesn't write latest ID mount (id=10) write transaction (id=11) crash mount [recovery process] transaction (id=11) transaction (id=12) <= valid transaction ID, but old commit must not replay Like above, this bug become the cause of recovery failure, or FS corruption. So why ->j_tail_sequence doesn't point latest ID? Because if checkpoint transactions was reclaimed by memory pressure (i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated. (And another case is, __jbd2_journal_clean_checkpoint_list() is called with empty transaction.) So in above cases, ->j_tail_sequence is not pointing latest transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not done too. So, to fix this problem with minimum changes, this patch updates ->j_tail_sequence, and issue REQ_FLUSH. (With more complex changes, some optimizations would be possible to avoid unnecessary REQ_FLUSH for example though.) BTW, journal->j_tail_sequence = ++journal->j_transaction_sequence; Increment of ->j_transaction_sequence seems to be unnecessary, but ext3 does this. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 50fe6dd1 upstream. Use the local uapi headers to keep in sync with "recently" added #define's (e.g. VSS_OP_REGISTER1). Fixes: 3eb2094c ("Adding makefile for tools/hv") Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 1f7c6658 upstream. Cirrus HD-audio driver may adjust GPIO pins for EAPD dynamically depending on the jack plug state. This works fine for the auto-mute mode where the speaker gets muted upon the HP jack plug. OTOH, when the auto-mute mode is off, this turns off the EAPD unexpectedly depending on the jack state, which results in the silent speaker output. This patch fixes the silent speaker output issue by setting GPIO bits constantly when the auto-mute mode is off. Reported-and-tested-by: moosotc@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 6ef2f68f upstream. This Lenovo ThinkCentre AIO also uses Line2 as mic mute button and uses GPIO2 to control the mic mute led, so applying this quirk can make both the button and led work. BugLink: https://bugs.launchpad.net/bugs/1555912Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 4f8e4f35 upstream. The current Intel HDMI codec driver supports only three fixed ports from port B to port D. However, i915 driver may assign a DP on other ports, e.g. port A, when no eDP is used. This incompatibility is caught later at pin_nid_to_pin_index() and results in a warning message like "HDMI: pin nid 4 not registered" at each time. This patch filters out such invalid events beforehand, so that the kernel won't be too grumbling. Reported-by:
Stefan Assmann <sassmann@kpanic.de> Signed-off-by:
-
Vittorio Gambaletta (VittGam) authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 4061db03 upstream. The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41 will often fail, so add a quirk entry to fix it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087Signed-off-by:
Vittorio Gambaletta <linuxbugs@vittgam.net> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 0ab1ace8 upstream. The commit [d507941b: ALSA: pcm: Correct PCM BUG error message] made the warning prefix back to "BUG:" due to its previous wrong prefix. But a kernel message containing "BUG:" seems taken as an Oops message wrongly by some brain-dead daemons, and it annoys users in the end. Instead of teaching daemons, change the string again to a more reasonable one. Fixes: 507941beb1e ('ALSA: pcm: Correct PCM BUG error message') Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 Fail all pending requests after surprise removal of a drive. Signed-off-by:
Vignesh Gunasekaran <vgunasekaran@micron.com> Signed-off-by:
Selvan Mani <smani@micron.com> Signed-off-by:
Asai Thambi S P <asamymuthupa@micron.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit abb0ccd1 upstream. Added timeout handler. Replaced blk_mq_end_request() with blk_mq_complete_request() to avoid double completion of a request. Signed-off-by:
Rajesh Kumar Sambandam <rsambandam@micron.com> Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit aae4a033 upstream. Allow device initialization to finish gracefully when it is in FTL rebuild failure state. Also, recover device out of this state after successfully secure erasing it. Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 51c6570e upstream. Flush inflight IOs using fsync_bdev() when the device is safely removed. Also, block further IOs in device open function. Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 59cf70e2 upstream. When FTL rebuild is in progress, alloc_disk() initializes the disk but device node will be created by add_disk() only after successful completion of FTL rebuild. So, skip deletion of device node in removal path when FTL rebuild is in progress. Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 5b7e0a8a upstream. Print exact time when an internal command is interrupted. Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit e35b9473 upstream. Remove setting and clearing MTIP_PF_EH_ACTIVE_BIT flag in mtip_handle_tfe() as they are redundant. Also avoid waking up service thread from mtip_handle_tfe() because it is already woken up in case of taskfile error. Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit cfc05bd3 upstream. Service thread does not detect the need for taskfile error hanlding. Fixed the flag condition to process taskfile error. Signed-off-by:
-
Asai Thambi SP authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit d8a18d2d upstream. Prevent standby immediate command from being issued in remove, suspend and shutdown paths, while drive is in FTL rebuild process. Signed-off-by:
-
Tiffany Lin authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 7df5ab87 upstream. In v4l2-compliance utility, test QUERYBUF required correct length value to go through each planar to check planar's length in multi-planar buffer type Signed-off-by:
Tiffany Lin <tiffany.lin@mediatek.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Philipp Zabel authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 74dc385c upstream. During the recent vb2_buffer restructuring, the calculation of the buffer payload reported to userspace was accidentally broken for the first encoded frame, counting only the length of the headers. This patch re-adds the length of the actual frame data. Fixes: 2d700715 ("[media] media: videobuf2: Restructure vb2_buffer") Reported-by:
Michael Olbrich <m.olbrich@pengutronix.de> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Tested-by:
Jan Luebbe <jlu@pengutronix.de> Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 5c915c68 upstream. On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max size results in a solid green rectangle being captured (all colors 0 in YUV). This turns out to be caused by max-width (924) not being a multiple of 16. We've likely never hit this problem before since normally xawtv / tvtime, etc. will prefer packed pixel formats. But when using a video card which is using xf86-video-modesetting + glamor, only planar XVideo fmts are available, and xawtv will chose a matching capture format to avoid needing to do conversion, triggering the solid green window problem. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
-
Hans Verkuil authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit b339a72e upstream. The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present. The adv7511 however still reported the EDID present after disconnecting the HDMI cable. Fix the logic regarding this control. And when the EDID is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver. This was also missing. Signed-off-by:
-
Hans de Goede authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 3e71da19 upstream. bytesperline should be the bytesperline for the first plane for planar formats, not that of all planes combined. This fixes a crash in xawtv caused by the wrong bpl. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305389Reported-and-tested-by:
Stas Sergeev <stsp@list.ru> Signed-off-by:
-
Sebastian Frias authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 0b41ce99 upstream. Some UART HW has a single register combining UART_DLL/UART_DLM (this was probably forgotten in the change that introduced the callbacks, commit b32b19b8) Fixes: b32b19b8 ("[SERIAL] 8250: set divisor register correctly ...") Signed-off-by:
Sebastian Frias <sf84@laposte.net> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 401879c5 upstream. The N_IRDA line discipline may access the previous line discipline's closed and already-fre private data on open [1]. The tty->disc_data field _never_ refers to valid data on entry to the line discipline's open() method. Rather, the ldisc is expected to initialize that field for its own use for the lifetime of the instance (ie. from open() to close() only). [1] ================================================================== BUG: KASAN: use-after-free in irtty_open+0x422/0x550 at addr ffff8800331dd068 Read of size 4 by task a.out/13960 ============================================================================= BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- ... Call Trace: [<ffffffff815fa2ae>] __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:279 [<ffffffff836938a2>] irtty_open+0x422/0x550 drivers/net/irda/irtty-sir.c:436 [<ffffffff829f1b80>] tty_ldisc_open.isra.2+0x60/0xa0 drivers/tty/tty_ldisc.c:447 [<ffffffff829f21c0>] tty_set_ldisc+0x1a0/0x940 drivers/tty/tty_ldisc.c:567 [< inline >] tiocsetd drivers/tty/tty_io.c:2650 [<ffffffff829da49e>] tty_ioctl+0xace/0x1fd0 drivers/tty/tty_io.c:2883 [< inline >] vfs_ioctl fs/ioctl.c:43 [<ffffffff816708ac>] do_vfs_ioctl+0x57c/0xe60 fs/ioctl.c:607 [< inline >] SYSC_ioctl fs/ioctl.c:622 [<ffffffff81671204>] SyS_ioctl+0x74/0x80 fs/ioctl.c:613 [<ffffffff852a7876>] entry_SYSCALL_64_fastpath+0x16/0x7a Reported-and-tested-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Peter Hurley authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit f33798de upstream. commit 9ce119f3 ("tty: Fix GPF in flush_to_ldisc()") fixed a GPF caused by a line discipline which does not define a receive_buf() method. However, the vt driver (and speakup driver also) pushes selection data directly to the line discipline receive_buf() method via tty_ldisc_receive_buf(). Fix the same problem in tty_ldisc_receive_buf(). Signed-off-by:
-
H Hartley Sweeten authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit bd3a3cd6 upstream. Memory mapped io (dev->mmio) should not also be writing to the ioport (dev->iobase) registers. Add the missing 'else' to these functions. Fixes: 0953ee4a ("staging: comedi: ni_mio_common: checkpatch.pl cleanup (else not useful)") Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Vladimir Zapolskiy authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit ccbc2a9e upstream. On error platform_device_register_simple() returns ERR_PTR() value, check for NULL always fails. The change corrects the check itself and propagates the returned error upwards. Fixes: 81fb0b90 ("staging: android: ion_test: unregister the platform device") Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Spencer E. Olson authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 1fd24a47 upstream. This fixes a bug in function ni_tio_input_inttrig(). The trigger number should be compared to cmd->start_arg, not cmd->start_src. Fixes: 6a760394 ("staging: comedi: ni_tiocmd: clarify the cmd->start_arg validation and use") Signed-off-by:
Spencer E. Olson <olsonse@umich.edu> Reviewed-by:
-
Benjamin Tissoires authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 4392bf33 upstream. hid_ignore_special_drivers works fine until hid_scan_report autodetects and reassign devices (for hid-multitouch, hid-microsoft and hid-rmi). Simplify the handling of the parameter: if it is there, use hid-generic, no matter what, and if not, scan the device or rely on the hid_have_special_driver table. This was detected while trying to disable hid-multitouch on a Surface Pro cover which prevented to use the keyboard. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Benjamin Tissoires authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 45c5c682 upstream. The Synaptics 0x11e5 over I2C found in the Asus T100-CHI requires to fetch the signature blob to actually start sending events. With this patch, we should be close enough to the Windows driver which checks the content of the blob at plugin to validate or not the touchscreen. Link: https://bugzilla.kernel.org/show_bug.cgi?id=113481 Fixes: 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") Signed-off-by:
-
Dmitry Torokhov authored
BugLink: http://bugs.launchpad.net/bugs/1572722 commit 3b654288 upstream. Even though hid_hw_* checks that passed in data_len is less than HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device reports and select largest size. In-kernel users normally just send as much data as report needs, so there is no problem, but hidraw users can do whatever they please: BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr ffffffc07135ea80 Write of size 4101 by task syz-executor/8747 CPU: 2 PID: 8747 Comm: syz-executor Tainted: G BU 3.18.0 #37 Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT) Call trace: [<ffffffc00020ebcc>] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83 [<ffffffc00020ee40>] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172 [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffc001958114>] dump_stack+0x90/0x140 lib/dump_stack.c:50 [< inline >] print_error_description mm/kasan/report.c:97 [< inline >] kasan_report_error mm/kasan/report.c:278 [<ffffffc0004597dc>] kasan_report+0x268/0x530 mm/kasan/report.c:305 [<ffffffc0004592e8>] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718 [<ffffffc0004594e0>] memcpy+0x30/0x54 mm/kasan/kasan.c:299 [<ffffffc001306354>] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178 [< inline >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321 [<ffffffc0013079a0>] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589 [<ffffffc001307ad8>] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602 [< inline >] hid_hw_output_report include/linux/hid.h:1039 [<ffffffc0012cc7a0>] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154 [<ffffffc0012cc7f4>] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177 [<ffffffc0004681dc>] vfs_write+0x1d4/0x3cc fs/read_write.c:534 [< inline >] SYSC_pwrite64 fs/read_write.c:627 [<ffffffc000468984>] SyS_pwrite64+0xec/0x144 fs/read_write.c:614 Object at ffffffc07135ea80, in cache kmalloc-512 Object allocated with size 268 bytes. Let's check data length against the buffer size before attempting to copy data over. Reported-by:
Alexander Potapenko <glider@google.com> Signed-off-by:
Dmitry Torokhov <dtor@chromium.org> Reviewed-by:
-
