- 16 Jan, 2019 15 commits
-
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 5ba6b4aa ] The driver currently silently accepts unsupported Wake-on-LAN modes (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user, which is confusing. Fixes: e2ca90c2 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Florian Fainelli authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit c4ce446e ] The driver currently silently accepts unsupported Wake-on-LAN modes (other than WAKE_PHY or WAKE_MAGIC) without reporting that to the user, which is confusing. Fixes: 2e55cc72 ("[PATCH] USB: usbnet (3/9) module for ASIX Ethernet adapters") Signed-off-by:
-
Lubomir Rintel authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit d85536cd ] Add missing prepare/unprepare operations for fbi->clk, this fixes following kernel warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:874 clk_core_enable+0x2c/0x1b0 Enabling unprepared disp0_clk Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc8-00032-g02b43ddd4f21-dirty #25 Hardware name: Marvell MMP2 (Device Tree Support) [<c010f7cc>] (unwind_backtrace) from [<c010cc6c>] (show_stack+0x10/0x14) [<c010cc6c>] (show_stack) from [<c011dab4>] (__warn+0xd8/0xf0) [<c011dab4>] (__warn) from [<c011db10>] (warn_slowpath_fmt+0x44/0x6c) [<c011db10>] (warn_slowpath_fmt) from [<c043898c>] (clk_core_enable+0x2c/0x1b0) [<c043898c>] (clk_core_enable) from [<c0439ec8>] (clk_core_enable_lock+0x18/0x2c) [<c0439ec8>] (clk_core_enable_lock) from [<c0436698>] (pxa168fb_probe+0x464/0x6ac) [<c0436698>] (pxa168fb_probe) from [<c04779a0>] (platform_drv_probe+0x48/0x94) [<c04779a0>] (platform_drv_probe) from [<c0475bec>] (driver_probe_device+0x328/0x470) [<c0475bec>] (driver_probe_device) from [<c0475de4>] (__driver_attach+0xb0/0x124) [<c0475de4>] (__driver_attach) from [<c0473c38>] (bus_for_each_dev+0x64/0xa0) [<c0473c38>] (bus_for_each_dev) from [<c0474ee0>] (bus_add_driver+0x1b8/0x230) [<c0474ee0>] (bus_add_driver) from [<c0476a20>] (driver_register+0xac/0xf0) [<c0476a20>] (driver_register) from [<c0102dd4>] (do_one_initcall+0xb8/0x1f0) [<c0102dd4>] (do_one_initcall) from [<c0b010a0>] (kernel_init_freeable+0x294/0x2e0) [<c0b010a0>] (kernel_init_freeable) from [<c07e9eb8>] (kernel_init+0x8/0x10c) [<c07e9eb8>] (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Exception stack(0xd008bfb0 to 0xd008bff8) bfa0: 00000000 00000000 00000000 00000000 bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace c0af40f9e2ed7cb4 ]--- Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> [b.zolnierkie: enhance patch description a bit] Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Matias Karhumaa authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit cb28c306 ] In case unpair_device() was called through mgmt interface at the same time when pairing was in progress, Bluetooth kernel module crash was seen. [ 600.351225] general protection fault: 0000 [#1] SMP PTI [ 600.351235] CPU: 1 PID: 11096 Comm: btmgmt Tainted: G OE 4.19.0-rc1+ #1 [ 600.351238] Hardware name: Dell Inc. Latitude E5440/08RCYC, BIOS A18 05/14/2017 [ 600.351272] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth] [ 600.351276] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01 [ 600.351279] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246 [ 600.351282] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60 [ 600.351285] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500 [ 600.351287] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00 [ 600.351290] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800 [ 600.351292] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00 [ 600.351295] FS: 00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000 [ 600.351298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 600.351300] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0 [ 600.351302] Call Trace: [ 600.351325] smp_failure+0x4f/0x70 [bluetooth] [ 600.351345] smp_cancel_pairing+0x74/0x80 [bluetooth] [ 600.351370] unpair_device+0x1c1/0x330 [bluetooth] [ 600.351399] hci_sock_sendmsg+0x960/0x9f0 [bluetooth] [ 600.351409] ? apparmor_socket_sendmsg+0x1e/0x20 [ 600.351417] sock_sendmsg+0x3e/0x50 [ 600.351422] sock_write_iter+0x85/0xf0 [ 600.351429] do_iter_readv_writev+0x12b/0x1b0 [ 600.351434] do_iter_write+0x87/0x1a0 [ 600.351439] vfs_writev+0x98/0x110 [ 600.351443] ? ep_poll+0x16d/0x3d0 [ 600.351447] ? ep_modify+0x73/0x170 [ 600.351451] do_writev+0x61/0xf0 [ 600.351455] ? do_writev+0x61/0xf0 [ 600.351460] __x64_sys_writev+0x1c/0x20 [ 600.351465] do_syscall_64+0x5a/0x110 [ 600.351471] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 600.351474] RIP: 0033:0x7fb2bdb62fe0 [ 600.351477] Code: 73 01 c3 48 8b 0d b8 6e 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 69 c7 2c 00 00 75 10 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 de 80 01 00 48 89 04 24 [ 600.351479] RSP: 002b:00007ffe062cb8f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 [ 600.351484] RAX: ffffffffffffffda RBX: 000000000255b3d0 RCX: 00007fb2bdb62fe0 [ 600.351487] RDX: 0000000000000001 RSI: 00007ffe062cb920 RDI: 0000000000000004 [ 600.351490] RBP: 00007ffe062cb920 R08: 000000000255bd80 R09: 0000000000000000 [ 600.351494] R10: 0000000000000353 R11: 0000000000000246 R12: 0000000000000001 [ 600.351497] R13: 00007ffe062cbbe0 R14: 0000000000000000 R15: 0000000000000000 [ 600.351501] Modules linked in: algif_hash algif_skcipher af_alg cmac ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c br_netfilter bridge stp llc overlay arc4 nls_iso8859_1 dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp dell_laptop kvm_intel crct10dif_pclmul dell_smm_hwmon crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_rapl_perf uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev media hid_multitouch input_leds joydev serio_raw dell_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic dell_smbios dcdbas sparse_keymap [ 600.351569] snd_hda_intel btusb snd_hda_codec btrtl btbcm btintel snd_hda_core bluetooth(OE) snd_hwdep snd_pcm iwlmvm ecdh_generic wmi_bmof dell_wmi_descriptor snd_seq_midi mac80211 snd_seq_midi_event lpc_ich iwlwifi snd_rawmidi snd_seq snd_seq_device snd_timer cfg80211 snd soundcore mei_me mei dell_rbtn dell_smo8800 mac_hid parport_pc ppdev lp parport autofs4 hid_generic usbhid hid i915 nouveau kvmgt vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi psmouse ahci sdhci_pci cqhci libahci fb_sys_fops sdhci drm e1000e video wmi [ 600.351637] ---[ end trace e49e9f1df09c94fb ]--- [ 600.351664] RIP: 0010:smp_chan_destroy.isra.10+0xce/0x2c0 [bluetooth] [ 600.351666] Code: c0 0f 84 b4 01 00 00 80 78 28 04 0f 84 53 01 00 00 4d 85 ed 0f 85 ab 00 00 00 48 8b 08 48 8b 50 08 be 10 00 00 00 48 89 51 08 <48> 89 0a 48 b9 00 02 00 00 00 00 ad de 48 89 48 08 48 8b 83 00 01 [ 600.351669] RSP: 0018:ffffa9be839b3b50 EFLAGS: 00010246 [ 600.351672] RAX: ffff9c999ac565a0 RBX: ffff9c9996e98c00 RCX: ffff9c999aa28b60 [ 600.351674] RDX: dead000000000200 RSI: 0000000000000010 RDI: ffff9c999e403500 [ 600.351676] RBP: ffffa9be839b3b70 R08: 0000000000000000 R09: ffffffff92a25c00 [ 600.351679] R10: ffffa9be839b3ae8 R11: 0000000000000001 R12: ffff9c995375b800 [ 600.351681] R13: 0000000000000000 R14: ffff9c99619a5000 R15: ffff9c9962a01c00 [ 600.351684] FS: 00007fb2be27c700(0000) GS:ffff9c999e880000(0000) knlGS:0000000000000000 [ 600.351686] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 600.351689] CR2: 00007fb2bdadbad0 CR3: 000000041c328001 CR4: 00000000001606e0 Crash happened because list_del_rcu() was called twice for smp->ltk. This was possible if unpair_device was called right after ltk was generated but before keys were distributed. In this commit smp_cancel_pairing was refactored to cancel pairing if it is in progress and otherwise just removes keys. Once keys are removed from rcu list, pointers to smp context's keys are set to NULL to make sure removed list items are not accessed later. This commit also adjusts the functionality of mgmt unpair_device() little bit. Previously pairing was canceled only if pairing was in state that keys were already generated. With this commit unpair_device() cancels pairing already in earlier states. Bug was found by fuzzing kernel SMP implementation using Synopsys Defensics. Reported-by:
Pekka Oikarainen <pekka.oikarainen@synopsys.com> Signed-off-by:
Matias Karhumaa <matias.karhumaa@gmail.com> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Martin Willi authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 28ef8b49 ] The allocation of hwsim radio identifiers uses a post-increment from 0, so the first radio has idx 0. This idx is explicitly excluded from multicast announcements ever since, but it is unclear why. Drop that idx check and announce the first radio as well. This makes userspace happy if it relies on these events. Signed-off-by:
Martin Willi <martin@strongswan.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sean Tranchetti authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 32bf94fb ] XFRM mode parameters passed as part of the user templates in the IP_XFRM_POLICY are never properly validated. Passing values other than valid XFRM modes can cause stack-out-of-bounds reads to occur later in the XFRM processing: [ 140.535608] ================================================================ [ 140.543058] BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x17e4/0x1cc4 [ 140.550306] Read of size 4 at addr ffffffc0238a7a58 by task repro/5148 [ 140.557369] [ 140.558927] Call trace: [ 140.558936] dump_backtrace+0x0/0x388 [ 140.558940] show_stack+0x24/0x30 [ 140.558946] __dump_stack+0x24/0x2c [ 140.558949] dump_stack+0x8c/0xd0 [ 140.558956] print_address_description+0x74/0x234 [ 140.558960] kasan_report+0x240/0x264 [ 140.558963] __asan_report_load4_noabort+0x2c/0x38 [ 140.558967] xfrm_state_find+0x17e4/0x1cc4 [ 140.558971] xfrm_resolve_and_create_bundle+0x40c/0x1fb8 [ 140.558975] xfrm_lookup+0x238/0x1444 [ 140.558977] xfrm_lookup_route+0x48/0x11c [ 140.558984] ip_route_output_flow+0x88/0xc4 [ 140.558991] raw_sendmsg+0xa74/0x266c [ 140.558996] inet_sendmsg+0x258/0x3b0 [ 140.559002] sock_sendmsg+0xbc/0xec [ 140.559005] SyS_sendto+0x3a8/0x5a8 [ 140.559008] el0_svc_naked+0x34/0x38 [ 140.559009] [ 140.592245] page dumped because: kasan: bad access detected [ 140.597981] page_owner info is not active (free page?) [ 140.603267] [ 140.653503] ================================================================ Signed-off-by:
Sean Tranchetti <stranche@codeaurora.org> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Thomas Petazzoni authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 3a58ac65 ] IO_SPACE_LIMIT is the ending address of the PCI IO space, i.e something like 0xfffff (and not 0x100000). Therefore, when offset = 0xf0000 is passed as argument, this function fails even though the offset + SZ_64K fits below the IO_SPACE_LIMIT. This makes the last chunk of 64 KB of the I/O space not usable as it cannot be mapped. This patch fixes that by substracing 1 to offset + SZ_64K, so that we compare the addrss of the last byte of the I/O space against IO_SPACE_LIMIT instead of the address of the first byte of what is after the I/O space. Fixes: c2794437 ("ARM: Add fixed PCI i/o mapping") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Andrei Otcheretianski authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 24f33e64 ] Core regulatory hints didn't set wiphy_idx to WIPHY_IDX_INVALID. Since the regulatory request is zeroed, wiphy_idx was always implicitly set to 0. This resulted in updating only phy #0. Fix that. Fixes: 806a9e39 ("cfg80211: make regulatory_request use wiphy_idx instead of wiphy") Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> [add fixes tag] Signed-off-by:
-
Andrei Otcheretianski authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 8682250b ] If a frame is dropped for any reason, mac80211 wouldn't report the TX status back to user space. As the user space may rely on the TX_STATUS to kick its state machines, resends etc, it's better to just report this frame as not acked instead. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 215ab0f0 ] After commit d6990976 ("vti6: fix PMTU caching and reporting on xmit"), some too big skbs might be potentially passed down to __xfrm6_output, causing it to fail to transmit but not free the skb, causing a leak of skb, and consequentially a leak of dst references. After running pmtu.sh, that shows as failure to unregister devices in a namespace: [ 311.397671] unregister_netdevice: waiting for veth_b to become free. Usage count = 1 The fix is to call kfree_skb in case of transmit failures. Fixes: dd767856 ("xfrm6: Don't call icmpv6_send on local error") Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Reviewed-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
-
Steffen Klassert authored
BugLink: https://bugs.launchpad.net/bugs/1810807 [ Upstream commit 07bf7908 ] We don't validate the address prefix lengths in the xfrm selector we got from userspace. This can lead to undefined behaviour in the address matching functions if the prefix is too big for the given address family. Fix this by checking the prefixes and refuse SA/policy insertation when a prefix is invalid. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
Air Icy <icytxw@gmail.com> Signed-off-by:
-
Keith Busch authored
BugLink: https://launchpad.net/bugs/1807393 If an IO timeout occurs, it's helpful to know if the controller did not post a completion or the driver missed an interrupt. While we never expect the latter, this patch will make it possible to tell the difference so we don't have to guess. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Tested-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Guilherme G. Piccoli <gpiccoli@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Jesse Brandeburg authored
BugLink: https://bugs.launchpad.net/bugs/1802421 As part of preparation for the rx-refactor, remove the packet split receive routine and ancillary code. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (backported from commit b32bfa17) Signed-off-by:
Daniel Axtens <daniel.axtens@canonical.com> Acked-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1806818 I210 ethernet card doesn't wakeup when a cable gets plugged. It's because its PME is not set. Since commit 42eca230 ("PCI: Don't touch card regs after runtime suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops calling pci_finish_runtime_suspend(), which enables the PCI PME. To fix the issue, let's not to save PCI states when it's runtime suspend, to let the PCI subsytem enables PME. Fixes: 42eca230 ("PCI: Don't touch card regs after runtime suspend D3") Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> (cherry picked from commit c881c486761fd093d104fa86e373e504aa60f35e git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Kleber Sacilotto de Souza authored
Ignore: yes Signed-off-by:
-
- 05 Dec, 2018 16 commits
-
-
Khalid Elmously authored
Signed-off-by: -
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1806569Signed-off-by:
-
Siva Rebbagondla authored
BugLink: https://bugs.launchpad.net/bugs/1804360 When Association timeout happens and station tries to scan, observed below firmware assert. Root cause: When association starts, driver is sending station add peer notify to firmware but when Association timeout happens, driver is not sending station peer delete to Firmware. Hence, FW is going into DEEP SLEEP in associated state, which causes below Firmware assert. Fix: sending station delete peer notify when assoc timeout happens ...skipping... wlan0: authenticate with ac:a3:1e:a1:1e:85 wlan0: send auth to ac:a3:1e:a1:1e:85 (try 1/3) wlan0: authenticated wlan0: associate with ac:a3:1e:a1:1e:85 (try 1/3) wlan0: associate with ac:a3:1e:a1:1e:85 (try 2/3) wlan0: associate with ac:a3:1e:a1:1e:85 (try 3/3) wlan0: association with ac:a3:1e:a1:1e:85 timed out ven_rsi_91x: rsi_disable_ps: Cannot accept disable PS in PS_NONE state ven_rsi_91x: rsi_interrupt_handler: ==> FIRMWARE Assert <== ven_rsi_91x: rsi_interrupt_handler: Firmware Status is 0xa IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Signed-off-by:
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Acked-By:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-By:
Shrirang Bagul <shrirang.bagul@canonical.com> Signed-off-by:
-
Thomas Gleixner authored
CVE-2018-12896 The posix timer overrun handling is broken because the forwarding functions can return a huge number of overruns which does not fit in an int. As a consequence timer_getoverrun(2) and siginfo::si_overrun can turn into random number generators. The k_clock::timer_forward() callbacks return a 64 bit value now. Make k_itimer::ti_overrun[_last] 64bit as well, so the kernel internal accounting is correct. 3Remove the temporary (int) casts. Add a helper function which clamps the overrun value returned to user space via timer_getoverrun(2) or siginfo::si_overrun limited to a positive value between 0 and INT_MAX. INT_MAX is an indicator for user space that the overrun value has been clamped. Reported-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Link: https://lkml.kernel.org/r/20180626132705.018623573@linutronix.de (backported from commit 78c9c4df) [ kmously: Mostly context adjustments or adjusting for slightly refactored code. A cosmetic change from the original (changing '-1' to '-1LL') was dropped because it's not applicable ] Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
-
John Garry authored
Currently smatch warns of possible Spectre-V1 issue in ahci_led_store(): drivers/ata/libahci.c:1150 ahci_led_store() warn: potential spectre issue 'pp->em_priv' (local cap) Userspace controls @pmp from following callchain: em_message->store() ->ata_scsi_em_message_store() -->ap->ops->em_store() --->ahci_led_store() After the mask+shift @pmp is effectively an 8b value, which is used to index into an array of length 8, so sanitize the array index. Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> CVE-2017-5753 (cherry picked from commit fae2a637) Signed-off-by:
-
Gustavo A. R. Silva authored
pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev' drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev' Fix this by sanitizing pdev_nr and rhport before using them to index vhcis and vhci->vhci_hcd_ss->vdev respectively. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> CVE-2017-5753 (backported from commit a0d6ec88) [juergh: - Adjusted context. - Dropped the modification of valid_port() (not in Xenial) and modified the port checks in valid_args() and store_detach() instead().] Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, a few places in ALSA control core codes may expand the array directly from the user-space value with speculation: sound/core/control.c:1003 snd_ctl_elem_lock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:1031 snd_ctl_elem_unlock() warn: potential spectre issue 'kctl->vd' sound/core/control.c:844 snd_ctl_elem_info() warn: potential spectre issue 'kctl->vd' sound/core/control.c:891 snd_ctl_elem_read() warn: potential spectre issue 'kctl->vd' sound/core/control.c:939 snd_ctl_elem_write() warn: potential spectre issue 'kctl->vd' Although all these seem doing only the first load without further reference, we may want to stay in a safer side, so hardening with array_index_nospec() would still make sense. In this patch, we put array_index_nospec() to the common snd_ctl_get_ioff*() helpers instead of each caller. These helpers are also referred from some drivers, too, and basically all usages are to calculate the array index from the user-space value, hence it's better to cover there. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> CVE-2017-5753 (backported from commit 088e861e) [juergh: Adjusted context.] Signed-off-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in RME9652 driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/rme9652.c:2074 snd_rme9652_channel_info() warn: potential spectre issue 'rme9652->channel_map' (local cap) This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in HDSP MADI driver may expand the array directly from the user-space value with speculation: sound/pci/rme9652/hdspm.c:5717 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_out' (local cap) sound/pci/rme9652/hdspm.c:5734 snd_hdspm_channel_info() warn: potential spectre issue 'hdspm->channel_map_in' (local cap) This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, a couple of places in ASIHPI driver may expand the array directly from the user-space value with speculation: sound/pci/asihpi/hpimsginit.c:70 hpi_init_response() warn: potential spectre issue 'res_size' (local cap) sound/pci/asihpi/hpioctl.c:189 asihpi_hpi_ioctl() warn: potential spectre issue 'adapters' This patch puts array_index_nospec() for hardening against them. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Takashi Iwai authored
As recently Smatch suggested, one place in OPL3 driver may expand the array directly from the user-space value with speculation: sound/drivers/opl3/opl3_synth.c:476 snd_opl3_set_voice() warn: potential spectre issue 'snd_opl3_regmap' This patch puts array_index_nospec() for hardening against it. BugLink: https://marc.info/?l=linux-kernel&m=152411496503418&w=2Reported-by:
-
Young_X authored
There is another cast from unsigned long to int which causes a bounds check to fail with specially crafted input. The value is then used as an index in the slot array in cdrom_slot_status(). This issue is similar to CVE-2018-16658 and CVE-2018-10940. Signed-off-by:
Young_X <YangX92@hotmail.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> CVE-2018-18710 (cherry picked from commit e4f3aa2e) Signed-off-by:
-
Darrick J. Wong authored
Kanda Motohiro reported that expanding a tiny xattr into a large xattr fails on XFS because we remove the tiny xattr from a shortform fork and then try to re-add it after converting the fork to extents format having not removed the ATTR_REPLACE flag. This fails because the attr is no longer present, causing a fs shutdown. This is derived from the patch in his bug report, but we really shouldn't ignore a nonzero retval from the remove call. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199119 Reported-by: kanda.motohiro@gmail.com Reviewed-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Darrick J. Wong <darrick.wong@oracle.com> CVE-2018-18690 (cherry picked from commit 7b38460d) Signed-off-by:
-
Laxman Dewangan authored
Use devm_pinctrl_register() for pin control registration and clean error path. Signed-off-by:
Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> CVE-2017-18174 (cherry picked from commit 251e22ab) Signed-off-by:
-
Laxman Dewangan authored
Add device managed APIs devm_pinctrl_register() and devm_pinctrl_unregister() for the APIs pinctrl_register() and pinctrl_unregister(). This helps in reducing code in error path and sometimes removal of .remove callback for driver unbind. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Khalid Elmously authored
Ignore: yes Signed-off-by:
-
- 13 Nov, 2018 9 commits
-
-
Khalid Elmously authored
Signed-off-by: -
Khalid Elmously authored
BugLink: https://bugs.launchpad.net/bugs/1802776Signed-off-by:
-
Eric W. Biederman authored
BugLink: https://launchpad.net/bugs/1789161 Jonathan Calmels from NVIDIA reported that he's able to bypass the mount visibility security check in place in the Linux kernel by using a combination of the unbindable property along with the private mount propagation option to allow a unprivileged user to see a path which was purposefully hidden by the root user. Reproducer: # Hide a path to all users using a tmpfs root@castiana:~# mount -t tmpfs tmpfs /sys/devices/ root@castiana:~# # As an unprivileged user, unshare user namespace and mount namespace stgraber@castiana:~$ unshare -U -m -r # Confirm the path is still not accessible root@castiana:~# ls /sys/devices/ # Make /sys recursively unbindable and private root@castiana:~# mount --make-runbindable /sys root@castiana:~# mount --make-private /sys # Recursively bind-mount the rest of /sys over to /mnnt root@castiana:~# mount --rbind /sys/ /mnt # Access our hidden /sys/device as an unprivileged user root@castiana:~# ls /mnt/devices/ breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual Solve this by teaching copy_tree to fail if a mount turns out to be both unbindable and locked. Cc: stable@vger.kernel.org Fixes: 5ff9d8a6 ("vfs: Lock in place mounts from more privileged users") Reported-by:
Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> (cherry picked from commit df7342b2) Signed-off-by:
Colin King <colin.king@canonical.com> Acked-by:
-
Eric W. Biederman authored
BugLink: https://launchpad.net/bugs/1789161 It was recently pointed out that the one instance of testing MNT_LOCKED outside of the namespace_sem is in ksys_umount. Fix that by adding a test inside of do_umount with namespace_sem and the mount_lock held. As it helps to fail fails the existing test is maintained with an additional comment pointing out that it may be racy because the locks are not held. Cc: stable@vger.kernel.org Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Fixes: 5ff9d8a6 ("vfs: Lock in place mounts from more privileged users") Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 Recently was noticed in an HP GEN9 system that kdump couldn't succeed due to an irq storm coming from an Intel NIC, narrowed down to be lack of clearing the MSI/MSI-X enable bits during the kdump kernel boot. For that, we need an early quirk to manually turn off MSI/MSI-X for PCI devices - this was worked as an optional boot parameter in a (~subsequent~) previous patch. Problem is that in our test system, the Intel NICs were not present in any secondary bus under the first PCIe root complex, so they couldn't be reached by the recursion in check_dev_quirk(). Modern systems, specially with multi-processors and multiple NUMA nodes expose multiple root complexes, describing more than one PCI hierarchy domain. Currently the simple recursion present in the early-quirks code from x86 starts a descending recursion from bus 0000:00, and reach many other busses by navigating this hierarchy walking through the bridges. This is not enough in systems with more than one root complex/host bridge, since the recursion won't "traverse" to other root complexes by starting statically in 0000:00 (for more details, see [0]). This patch hence implements the full bus/device/function scan in early_quirks(), by checking all possible busses instead of using a recursion based on the first root bus or limiting the search scope to the first 32 busses (like it was done in the beginning [1]). [0] https://bugs.launchpad.net/bugs/1797990 [1] From historical perspective, early PCI scan dates back to BitKeeper, added by Andi Kleen's "[PATCH] APIC fixes for x86-64", on October/2003. It initially restricted the search to the first 32 busses and slots. Due to a potential bug found in Nvidia chipsets, the scan was changed to run only in the first root bus: see commit 8659c406 ("x86: only scan the root bus in early PCI quirks") Finally, secondary busses reachable from the 1st bus were re-added back by: commit 850c3210 ("x86/quirks: Reintroduce scanning of secondary buses") Reported-by:
Dan Streetman <ddstreet@canonical.com> Signed-off-by:
Mauricio Faria de Oliveira <mfo@canonical.com> Acked-by:
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 We observed a kdump failure in x86 that was narrowed down to MSI irq storm coming from a PCI network device. The bug manifests as a lack of progress in the boot process of kdump kernel, and a flood of kernel messages like: [...] [ 342.265294] do_IRQ: 0.155 No irq handler for vector [ 342.266916] do_IRQ: 0.155 No irq handler for vector [ 347.258422] do_IRQ: 14053260 callbacks suppressed [...] The root cause of the issue is that kexec process of the kdump kernel doesn't ensure PCI devices are reset or MSI capabilities are disabled, so a PCI adapter could produce a huge amount of irqs which would steal all the processing time for the CPU (specially since we usually restrict kdump kernel to use a single CPU only). This patch implements the kernel parameter "pci=clearmsi" to clear the MSI/MSI-X enable bits in the Message Control register for all PCI devices during early boot time, thus preventing potential issues in the kexec'ed kernel. PCI spec also supports/enforces this need (see PCI Local Bus spec sections 6.8.1.3 and 6.8.2.3). Suggested-by:
Gavin Shan <shan.gavin@linux.alibaba.com> Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: https://bugs.launchpad.net/bugs/1797990 This patch exports (and renames) the function find_cap() to be used in the early PCI quirk code, by the next patch. This is being moved out from AGP code to generic early-PCI code since it's not AGP-specific and can be used for any PCI device. No functional changes intended. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1802341 In ena_remove() we have the following stack call: ena_remove() unregister_netdev() ena_destroy_device() netif_carrier_off() Calling netif_carrier_off() causes linkwatch to try to handle the link change event on the already unregistered netdev, which leads to a read from an unreadable memory address. This patch switches the order of the two functions, so that netif_carrier_off() is called on a regiestered netdev. To accomplish this fix we also had to: 1. Remove the set bit ENA_FLAG_TRIGGER_RESET 2. Add a sanitiy check in ena_close() both to prevent double device reset (when calling unregister_netdev() ena_close is called, but the device was already deleted in ena_destroy_device()). 3. Set the admin_queue running state to false to avoid using it after device was reset (for example when calling ena_destroy_all_io_queues() right after ena_com_dev_reset() in ena_down) Finally, driver version is also updated. Change-Id: I3cc1aafe9cb3701a6eaee44e00add0e175c93148 Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Tomasz Nowicki authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Implement pci_acpi_scan_root() and other arch-specific calls so ARM64 can use ACPI to setup and enumerate PCI buses. Use memory-mapped configuration space information from either the ACPI _CBA method or the MCFG table and the ECAM library and generic ECAM config accessor ops. Implement acpi_pci_bus_find_domain_nr() to retrieve the domain number from the acpi_pci_root structure. Implement pcibios_add_bus() and pcibios_remove_bus() to call acpi_pci_add_bus() and acpi_pci_remove_bus() for ACPI slot management and other configuration. Signed-off-by:
Tomasz Nowicki <tn@semihalf.com> Signed-off-by:
Jayachandran C <jchandra@broadcom.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> (backported from commit 0cb0786b) [ dannf: Kconfig offset fixup ] Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
-
