- 21 Oct, 2019 18 commits
-
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 5f924277 upstream. 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:
Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Benjamin Tissoires authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 061232f0 upstream. Kernel v4.9 strictly enforces DMA capable buffers, so we need to remove buffers allocated on the stack. [jkosina@suse.cz: fix up second usage of hid_hw_raw_request(), spotted by 0day build bot] Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Alan Stern authored
BugLink: https://bugs.launchpad.net/bugs/1848589 commit 98375b86 upstream. 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:
-
Marcel Holtmann authored
BugLink: https://bugs.launchpad.net/bugs/1848589 [ Upstream commit 68d19d7d ] This reverts commit c49a8682. There are devices which require low connection intervals for usable operation including keyboards and mice. Forcing a static connection interval for these types of devices has an impact in latency and causes a regression. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Shrirang Bagul authored
BugLink: https://bugs.launchpad.net/bugs/1847969 Due to a race condition, some times the headers directory already exists when running the install-arch-headers rule. Make sure we do not fail in that case. Signed-off-by:
Alfonso Sánchez-Beato <alfonso.sanchez-beato@canonical.com> Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Shrirang Bagul authored
BugLink: https://bugs.launchpad.net/bugs/1847969 Add a fit_signed option and a script so we can build FIT images that will be eventually signed. Signed-off-by:
-
Shile Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1840043 Read /sys/fs/bcache/<uuid>/cacheN/priority_stats can take very long time with huge cache after long run. Signed-off-by:
Shile Zhang <shile.zhang@linux.alibaba.com> Tested-by:
Heitor Alves de Siqueira <halves@canonical.com> Signed-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> (backported from commit d55a4ae9) Signed-off-by:
-
Heitor Alves de Siqueira authored
BugLink: https://bugs.launchpad.net/bugs/1848236Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Tyler Hicks authored
BugLink: https://launchpad.net/bugs/1847189 The Ubuntu Xenial backport of upstream commit 19b558db ("posix-timers: Protect posix clock array access against speculation") incorrectly dropped the NULL check on the .clock_getres function pointer. Readd the NULL check while still protecting against side-channel speculation attacks when indexing into the posix_clocks array to perform that NULL check. The NULL check protects against a denial of service (system crash) or possible arbitrary code execution that can be triggered by clock_gettime(10, 0), as pointed out by Vitaly Nikolenko. Fixes: eb4a3a43 ("posix-timers: Protect posix clock array access against speculation") Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
BugLink: https://bugs.launchpad.net/bugs/1847118 When looking for a bit by number we make use of the cached result from the preceding lookup to speed up operation. Firstly we check if the requested pfn is within the cached zone and if not lookup the new zone. We then check if the offset for that pfn falls within the existing cached node. This happens regardless of whether the node is within the zone we are now scanning. With certain memory layouts it is possible for this to false trigger creating a temporary alias for the pfn to a different bit. This leads the hibernation code to free memory which it was never allocated with the expected fallout. Ensure the zone we are scanning matches the cached zone before considering the cached node. Deep thanks go to Andrea for many, many, many hours of hacking and testing that went into cornering this bug. Reported-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (backported from commit 39800d8fc4083cfe5c8f69333336bf03f9571070 linux-next) Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_NFC socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
Ori Nimron <orinimron123@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> CVE-2019-17056 (cherry picked from commit 3a359798) Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_ISDN socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_APPLETALK socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_IEEE802154 socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
-
Ori Nimron authored
When creating a raw AF_AX25 socket, CAP_NET_RAW needs to be checked first. Signed-off-by:
-
Hui Peng authored
The `ar_usb` field of `ath6kl_usb_pipe_usb_pipe` objects are initialized to point to the containing `ath6kl_usb` object according to endpoint descriptors read from the device side, as shown below in `ath6kl_usb_setup_pipe_resources`: for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) { endpoint = &iface_desc->endpoint[i].desc; // get the address from endpoint descriptor pipe_num = ath6kl_usb_get_logical_pipe_num(ar_usb, endpoint->bEndpointAddress, &urbcount); ...... // select the pipe object pipe = &ar_usb->pipes[pipe_num]; // initialize the ar_usb field pipe->ar_usb = ar_usb; } The driver assumes that the addresses reported in endpoint descriptors from device side to be complete. If a device is malicious and does not report complete addresses, it may trigger NULL-ptr-deref `ath6kl_usb_alloc_urb_from_pipe` and `ath6kl_usb_free_urb_to_pipe`. This patch fixes the bug by preventing potential NULL-ptr-deref (CVE-2019-15098). Signed-off-by:Hui Peng <benquike@gmail.com> Reported-by:
Mathias Payer <mathias.payer@nebelwelt.net> Reviewed-by:
Kalle Valo <kvalo@codeaurora.org> CVE-2019-15098 (cherry picked from commit 39d170b3) Signed-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1844155 arch/arm/ defines a SIGMINSTKSZ of 2k, so we should use the same value for compat tasks. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Reviewed-by:
Dave Martin <Dave.Martin@arm.com> Reported-by:
Steve McIntyre <steve.mcintyre@arm.com> Tested-by:
Steve McIntyre <93sam@debian.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit 24951465) Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Juerg Haefliger <juergh@canonical.com>
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1844155 The sigaltstack(2) system call fails with -ENOMEM if the new alternative signal stack is found to be smaller than SIGMINSTKSZ. On architectures such as arm64, where the native value for SIGMINSTKSZ is larger than the compat value, this can result in an unexpected error being reported to a compat task. See, for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904385 This patch fixes the problem by extending do_sigaltstack to take the minimum signal stack size as an additional parameter, allowing the native and compat system call entry code to pass in their respective values. COMPAT_SIGMINSTKSZ is just defined as SIGMINSTKSZ if it has not been defined by the architecture. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Reported-by:
-
- 01 Oct, 2019 22 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by: -
Khalid Elmously authored
Ignore: yes Signed-off-by:
-
Kleber Sacilotto de Souza authored
BugLink: https://bugs.launchpad.net/bugs/1846069 Properties: no-test-build Signed-off-by:
-
Kleber Sacilotto de Souza authored
Ignore: yes Signed-off-by: -
Khalid Elmously authored
BugLink: http://bugs.launchpad.net/bugs/1786013Signed-off-by:
-
Jason Yan authored
CVE-2017-18232 In commit 87c8331f ("[SCSI] libsas: prevent domain rediscovery competing with ata error handling") introduced disco mutex to prevent rediscovery competing with ata error handling and put the whole revalidation in the mutex. But the rphy add/remove needs to wait for the error handling which also grabs the disco mutex. This may leads to dead lock.So the probe and destruct event were introduce to do the rphy add/remove asynchronously and out of the lock. The asynchronously processed workers makes the whole discovery process not atomic, the other events may interrupt the process. For example, if a loss of signal event inserted before the probe event, the sas_deform_port() is called and the port will be deleted. And sas_port_delete() may run before the destruct event, but the port-x:x is the top parent of end device or expander. This leads to a kernel WARNING such as: [ 82.042979] sysfs group 'power' not found for kobject 'phy-1:0:22' [ 82.042983] ------------[ cut here ]------------ [ 82.042986] WARNING: CPU: 54 PID: 1714 at fs/sysfs/group.c:237 sysfs_remove_group+0x94/0xa0 [ 82.043059] Call trace: [ 82.043082] [<ffff0000082e7624>] sysfs_remove_group+0x94/0xa0 [ 82.043085] [<ffff00000864e320>] dpm_sysfs_remove+0x60/0x70 [ 82.043086] [<ffff00000863ee10>] device_del+0x138/0x308 [ 82.043089] [<ffff00000869a2d0>] sas_phy_delete+0x38/0x60 [ 82.043091] [<ffff00000869a86c>] do_sas_phy_delete+0x6c/0x80 [ 82.043093] [<ffff00000863dc20>] device_for_each_child+0x58/0xa0 [ 82.043095] [<ffff000008696f80>] sas_remove_children+0x40/0x50 [ 82.043100] [<ffff00000869d1bc>] sas_destruct_devices+0x64/0xa0 [ 82.043102] [<ffff0000080e93bc>] process_one_work+0x1fc/0x4b0 [ 82.043104] [<ffff0000080e96c0>] worker_thread+0x50/0x490 [ 82.043105] [<ffff0000080f0364>] kthread+0xfc/0x128 [ 82.043107] [<ffff0000080836c0>] ret_from_fork+0x10/0x50 Make probe and destruct a direct call in the disco and revalidate function, but put them outside the lock. The whole discovery or revalidate won't be interrupted by other events. And the DISCE_PROBE and DISCE_DESTRUCT event are deleted as a result of the direct call. Introduce a new list to destruct the sas_port and put the port delete after the destruct. This makes sure the right order of destroying the sysfs kobject and fix the warning above. In sas_ex_revalidate_domain() have a loop to find all broadcasted device, and sometimes we have a chance to find the same expander twice. Because the sas_port will be deleted at the end of the whole revalidate process, sas_port with the same name cannot be added before this. Otherwise the sysfs will complain of creating duplicate filename. Since the LLDD will send broadcast for every device change, we can only process one expander's revalidation. [mkp: kbuild test robot warning] Signed-off-by:
Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (backported from commit 0558f33c) [ Connor Kuehl: The hunk that removed variants from 'enum discover_event' required manual placement. I did take the liberty of removing the hardcoded enum values from this enum as is done in upstream commit 0d78f969 "scsi: libsas: remove the numbering for each event enum" but only for this enum to reduce confusion over renumbering. It seemed overkill to take in the entire patch alongside this backport. ] Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Sanjay Konduri authored
CVE-2018-21008 Observed crash in some scenarios when assertion has occurred, this is because hw structure is freed and is tried to get accessed in some functions where null check is already present. So, avoided the crash by making the hw to NULL after freeing. Signed-off-by:
Sanjay Konduri <sanjay.konduri@redpinesignals.com> Signed-off-by:
Sushant Kumar Mishra <sushant.mishra@redpinesignals.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1845405Signed-off-by:
-
Cong Wang authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit 6efb971b ] When tcf_block_get() fails in sfb_init(), q->qdisc is still a NULL pointer which leads to a crash in sfb_destroy(). Similar for sch_dsmark. Instead of fixing each separately, Linus suggested to just accept NULL pointer in qdisc_put(), which would make callers easier. (For sch_dsmark, the bug probably exists long before commit 6529eaba.) Fixes: 6529eaba ("net: sched: introduce tcf block infractructure") Reported-by: syzbot+d5870a903591faaca4ae@syzkaller.appspotmail.com Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Vineet Gupta authored
BugLink: https://bugs.launchpad.net/bugs/1845405 This is a custom patch (no mainline equivalent) for stable backport only to address 0-Day kernel test infra ARC 4.x.y builds errors. The reason for this custom patch as that it is a single patch, touches only ARC, vs. atleast two 7c2c11b2, dc8635b7 which touch atleast 3 other arches (one long removed) and could potentially have a fallout. Reported-by:
kbuild test robot <lkp@intel.com> CC: stable@vger.kernel.org # 4.4, 4.9 Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Sean Young authored
BugLink: https://bugs.launchpad.net/bugs/1845405 commit 0c4df39e upstream. Ensure we do not access the buffer beyond the end if no 0xff byte is encountered. Reported-by: syzbot+eaaaf38a95427be88f4b@syzkaller.appspotmail.com Signed-off-by:
Sean Young <sean@mess.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Jann Horn authored
BugLink: https://bugs.launchpad.net/bugs/1845405 commit 52f6f9d7 upstream. As sparse points out, these two copy_from_user() should actually be copy_to_user(). Fixes: 229b53c9 ("take floppy compat ioctls to sodding floppy.c") Cc: stable@vger.kernel.org Acked-by:
Alexander Popov <alex.popov@linux.com> Reviewed-by:
Mukesh Ojha <mojha@codeaurora.org> Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
-
Hillf Danton authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit d41a3eff ] If a request_key authentication token key gets revoked, there's a window in which request_key_auth_describe() can see it with a NULL payload - but it makes no check for this and something like the following oops may occur: BUG: Kernel NULL pointer dereference at 0x00000038 Faulting instruction address: 0xc0000000004ddf30 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [...] request_key_auth_describe+0x90/0xd0 LR [...] request_key_auth_describe+0x54/0xd0 Call Trace: [...] request_key_auth_describe+0x54/0xd0 (unreliable) [...] proc_keys_show+0x308/0x4c0 [...] seq_read+0x3d0/0x540 [...] proc_reg_read+0x90/0x110 [...] __vfs_read+0x3c/0x70 [...] vfs_read+0xb4/0x1b0 [...] ksys_read+0x7c/0x130 [...] system_call+0x5c/0x70 Fix this by checking for a NULL pointer when describing such a key. Also make the read routine check for a NULL pointer to be on the safe side. [DH: Modified to not take already-held rcu lock and modified to also check in the read routine] Fixes: 04c567d9 ("[PATCH] Keys: Fix race between two instantiators of a key") Reported-by:
Sachin Sant <sachinp@linux.vnet.ibm.com> Signed-off-by:
Hillf Danton <hdanton@sina.com> Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
-
Wenwen Wang authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit 962411b0 ] If devm_request_irq() fails to disable all interrupts, no cleanup is performed before retuning the error. To fix this issue, invoke omap_dma_free() to do the cleanup. Signed-off-by:
Wenwen Wang <wenwen@cs.uga.edu> Acked-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/1565938570-7528-1-git-send-email-wenwen@cs.uga.eduSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Christophe JAILLET authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit e1e54ec7 ] In commit 99cd149e ("sgiseeq: replace use of dma_cache_wback_inv"), a call to 'get_zeroed_page()' has been turned into a call to 'dma_alloc_coherent()'. Only the remove function has been updated to turn the corresponding 'free_page()' into 'dma_free_attrs()'. The error hndling path of the probe function has not been updated. Fix it now. Rename the corresponding label to something more in line. Fixes: 99cd149e ("sgiseeq: replace use of dma_cache_wback_inv") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by:
-
Naoya Horiguchi authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit eeb71c95 ] turbostat could be terminated by general protection fault on some latest hardwares which (for example) support 9 levels of C-states and show 18 "tADDED" lines. That bloats the total output and finally causes buffer overrun. So let's extend the buffer to avoid this. Signed-off-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit 189308d5 ] A similar workaround for the suspend/resume problem is needed for yet another ASUS machines, P6X models. Like the previous fix, the BIOS doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_* entries are used instead. Reported-and-tested-by:
SteveM <swm@swm1.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit 478228e5 ] It's safer to zero out the password so that it can never be disclosed. Fixes: 0c219f5799c7 ("cifs: set domainName when a domain-key is used in multiuser") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Ronnie Sahlberg authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit f2aee329 ] RHBZ: 1710429 When we use a domain-key to authenticate using multiuser we must also set the domainnmame for the new volume as it will be used and passed to the server in the NTLMSSP Domain-name. Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
-
Trond Myklebust authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit d33d4beb ] Ensure we update the write result count on success, since the RPC call itself does not do so. Reported-by:
Jan Stancek <jstancek@redhat.com> Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Tested-by:
-
Trond Myklebust authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit 71affe9b ] If we received a reply from the server with a zero length read and no error, then that implies we are at eof. Signed-off-by:
-
Thomas Jarosch authored
BugLink: https://bugs.launchpad.net/bugs/1845405 [ Upstream commit 3a069024 ] The find_pattern() debug output was printing the 'skip' character. This can be a NULL-byte and messes up further pr_debug() output. Output without the fix: kernel: nf_conntrack_ftp: Pattern matches! kernel: nf_conntrack_ftp: Skipped up to `<7>nf_conntrack_ftp: find_pattern `PORT': dlen = 8 kernel: nf_conntrack_ftp: find_pattern `EPRT': dlen = 8 Output with the fix: kernel: nf_conntrack_ftp: Pattern matches! kernel: nf_conntrack_ftp: Skipped up to 0x0 delimiter! kernel: nf_conntrack_ftp: Match succeeded! kernel: nf_conntrack_ftp: conntrack_ftp: match `172,17,0,100,200,207' (20 bytes at 4150681645) kernel: nf_conntrack_ftp: find_pattern `PORT': dlen = 8 Signed-off-by:
Thomas Jarosch <thomas.jarosch@intra2net.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
