4.4.74-stable review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.4.74-stable review
This is the start of the stable review cycle for the 4.4.74 release. There are 30 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Jun 21 15:20:21 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.74-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.4.74-rc1
Hugh Dickins <[email protected]>
mm: larger stack guard gap, between vmas
Thomas Gleixner <[email protected]>
alarmtimer: Rate limit periodic intervals
Paul Burton <[email protected]>
MIPS: Fix bnezc/jialc return address calculation
Shuah Khan <[email protected]>
usb: dwc3: exynos fix axius clock error path to do cleanup
Thomas Gleixner <[email protected]>
alarmtimer: Prevent overflow of relative timers
Heiner Kallweit <[email protected]>
genirq: Release resources in __setup_irq() error path
Yu Zhao <[email protected]>
swap: cond_resched in swap_cgroup_prepare()
James Morse <[email protected]>
mm/memory-failure.c: use compound_head() flags for huge pages
Alan Stern <[email protected]>
USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
Corentin Labbe <[email protected]>
usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk
Dan Carpenter <[email protected]>
drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR()
Chris Brandt <[email protected]>
usb: r8a66597-hcd: decrease timeout
Chris Brandt <[email protected]>
usb: r8a66597-hcd: select a different endpoint on timeout
Johan Hovold <[email protected]>
USB: gadget: dummy_hcd: fix hub-descriptor removable fields
Arnd Bergmann <[email protected]>
pvrusb2: reduce stack usage pvr2_eeprom_analyze()
Anton Bondarenko <[email protected]>
usb: core: fix potential memory leak in error path during hcd creation
Johan Hovold <[email protected]>
USB: hub: fix SS max number of ports
Matt Ranostay <[email protected]>
iio: proximity: as3935: recalibrate RCO after resume
Dan Carpenter <[email protected]>
staging: rtl8188eu: prevent an underflow in rtw_check_beacon_data()
Tony Lindgren <[email protected]>
mfd: omap-usb-tll: Fix inverted bit use for USB TLL mode
Laura Abbott <[email protected]>
x86/mm/32: Set the '__vmalloc_start_set' flag in initmem_init()
Christophe JAILLET <[email protected]>
serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'
Johannes Berg <[email protected]>
mac80211: fix IBSS presp allocation size
Koen Vandeputte <[email protected]>
mac80211: fix CSA in IBSS mode
Jason A. Donenfeld <[email protected]>
mac80211/wpa: use constant time memory comparison for MACs
Emmanuel Grumbach <[email protected]>
mac80211: don't look at the PM bit of BAR frames
Christophe JAILLET <[email protected]>
vb2: Fix an off by one error in 'vb2_plane_vaddr'
Tomasz Wilczyński <[email protected]>
cpufreq: conservative: Allow down_threshold to take values from 1 to 10
Marc Kleine-Budde <[email protected]>
can: gs_usb: fix memory leak in gs_cmd_reset()
Nicholas Bellinger <[email protected]>
configfs: Fix race between create_link and configfs_rmdir
-------------
Diffstat:
Documentation/kernel-parameters.txt | 7 ++ Makefile | 4 +- arch/arc/mm/mmap.c | 2 +- arch/arm/mm/mmap.c | 4 +- arch/frv/mm/elf-fdpic.c | 2 +- arch/mips/kernel/branch.c | 4 +- arch/mips/mm/mmap.c | 2 +- arch/parisc/kernel/sys_parisc.c | 15 +-- arch/powerpc/mm/slice.c | 2 +- arch/s390/mm/mmap.c | 4 +- arch/sh/mm/mmap.c | 4 +- arch/sparc/kernel/sys_sparc_64.c | 4 +- arch/sparc/mm/hugetlbpage.c | 2 +- arch/tile/mm/hugetlbpage.c | 2 +- arch/x86/kernel/sys_x86_64.c | 4 +- arch/x86/mm/hugetlbpage.c | 2 +- arch/x86/mm/numa_32.c | 1 + arch/xtensa/kernel/syscall.c | 2 +- drivers/cpufreq/cpufreq_conservative.c | 4 +- drivers/iio/proximity/as3935.c | 6 +- drivers/media/usb/pvrusb2/pvrusb2-eeprom.c | 13 +-- drivers/media/v4l2-core/videobuf2-core.c | 2 +- drivers/mfd/omap-usb-tll.c | 2 +- drivers/misc/c2port/c2port-duramar2150.c | 4 +- drivers/net/can/usb/gs_usb.c | 2 + drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +- drivers/tty/serial/efm32-uart.c | 11 ++- drivers/usb/core/hcd.c | 1 + drivers/usb/core/hub.c | 8 +- drivers/usb/dwc3/dwc3-exynos.c | 4 +- drivers/usb/gadget/legacy/inode.c | 5 +- drivers/usb/gadget/udc/dummy_hcd.c | 19 ++-- drivers/usb/gadget/udc/net2280.c | 9 +- drivers/usb/host/r8a66597-hcd.c | 6 +- drivers/usb/host/xhci-pci.c | 3 + fs/configfs/symlink.c | 3 +- fs/hugetlbfs/inode.c | 2 +- fs/proc/task_mmu.c | 4 - include/linux/mm.h | 55 +++++------ include/uapi/linux/usb/ch11.h | 3 + kernel/irq/manage.c | 4 +- kernel/time/alarmtimer.c | 14 ++- mm/gup.c | 5 - mm/memory-failure.c | 5 +- mm/memory.c | 38 -------- mm/mmap.c | 147 +++++++++++++++++------------ mm/swap_cgroup.c | 3 + net/mac80211/ibss.c | 6 +- net/mac80211/rx.c | 6 +- net/mac80211/wpa.c | 9 +- 50 files changed, 245 insertions(+), 227 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/30 configfs: Fix race between create_link and configfs_rmdir
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Bellinger <[email protected]>
commit ba80aa909c99802c428682c352b0ee0baac0acd3 upstream.
This patch closes a long standing race in configfs between the creation of a new symlink in create_link(), while the symlink target's config_item is being concurrently removed via configfs_rmdir().
This can happen because the symlink target's reference is obtained by config_item_get() in create_link() before the CONFIGFS_USET_DROPPING bit set by configfs_detach_prep() during configfs_rmdir() shutdown is actually checked..
This originally manifested itself on ppc64 on v4.8.y under heavy load using ibmvscsi target ports with Novalink API:
[ 7877.289863] rpadlpar_io: slot U8247.22L.212A91A-V1-C8 added
[ 7879.893760] ------------[ cut here ]------------
[ 7879.893768] WARNING: CPU: 15 PID: 17585 at ./include/linux/kref.h:46 config_item_get+0x7c/0x90 [configfs]
[ 7879.893811] CPU: 15 PID: 17585 Comm: targetcli Tainted: G O 4.8.17-customv2.22 #12
[ 7879.893812] task: c00000018a0d3400 task.stack: c0000001f3b40000
[ 7879.893813] NIP: d000000002c664ec LR: d000000002c60980 CTR: c000000000b70870
[ 7879.893814] REGS: c0000001f3b43810 TRAP: 0700 Tainted: G O (4.8.17-customv2.22)
[ 7879.893815] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28222242 XER: 00000000
[ 7879.893820] CFAR: d000000002c664bc SOFTE: 1
GPR00: d000000002c60980 c0000001f3b43a90 d000000002c70908 c0000000fbc06820
GPR04: c0000001ef1bd900 0000000000000004 0000000000000001 0000000000000000
GPR08: 0000000000000000 0000000000000001 d000000002c69560 d000000002c66d80
GPR12: c000000000b70870 c00000000e798700 c0000001f3b43ca0 c0000001d4949d40
GPR16: c00000014637e1c0 0000000000000000 0000000000000000 c0000000f2392940
GPR20: c0000001f3b43b98 0000000000000041 0000000000600000 0000000000000000
GPR24: fffffffffffff000 0000000000000000 d000000002c60be0 c0000001f1dac490
GPR28: 0000000000000004 0000000000000000 c0000001ef1bd900 c0000000f2392940
[ 7879.893839] NIP [d000000002c664ec] config_item_get+0x7c/0x90 [configfs]
[ 7879.893841] LR [d000000002c60980] check_perm+0x80/0x2e0 [configfs]
[ 7879.893842] Call Trace:
[ 7879.893844] [c0000001f3b43ac0] [d000000002c60980] check_perm+0x80/0x2e0 [configfs]
[ 7879.893847] [c0000001f3b43b10] [c000000000329770] do_dentry_open+0x2c0/0x460
[ 7879.893849] [c0000001f3b43b70] [c000000000344480] path_openat+0x210/0x1490
[ 7879.893851] [c0000001f3b43c80] [c00000000034708c] do_filp_open+0xfc/0x170
[ 7879.893853] [c0000001f3b43db0] [c00000000032b5bc] do_sys_open+0x1cc/0x390
[ 7879.893856] [c0000001f3b43e30] [c000000000009584] system_call+0x38/0xec
[ 7879.893856] Instruction dump:
[ 7879.893858] 409d0014 38210030 e8010010 7c0803a6 4e800020 3d220000 e94981e0 892a0000
[ 7879.893861] 2f890000 409effe0 39200001 992a0000 <0fe00000> 4bffffd0 60000000 60000000
[ 7879.893866] ---[ end trace 14078f0b3b5ad0aa ]---To close this race, go ahead and obtain the symlink's target config_item reference only after the existing CONFIGFS_USET_DROPPING check succeeds.
This way, if configfs_rmdir() wins create_link() will return -ENONET, and if create_link() wins configfs_rmdir() will return -EBUSY.
--- fs/configfs/symlink.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/configfs/symlink.c +1 -2
@@ -83,14 +83,13 @@ static int create_link(struct config_ite ret = -ENOMEM ; sl =kmalloc (sizeof (struct configfs_symlink ),GFP_KERNEL );if (sl) { - sl->sl_target =config_item_get (item);spin_lock (&configfs_dirent_lock);if (target_sd->s_type &CONFIGFS_USET_DROPPING ) {spin_unlock (&configfs_dirent_lock); -config_item_put (item);kfree (sl);return -ENOENT ; } + sl->sl_target =config_item_get (item);list_add (&sl->sl_list, &target_sd->s_links);spin_unlock (&configfs_dirent_lock); ret = configfs_create_link(sl, parent_item->ci_dentry,
Greg Kroah-Hartman
maintainerPATCH 2/30 can: gs_usb: fix memory leak in gs_cmd_reset()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Kleine-Budde <[email protected]>
commit 5cda3ee5138e91ac369ed9d0b55eab0dab077686 upstream.
This patch adds the missing kfree() in gs_cmd_reset() to free the memory that is not used anymore after usb_control_msg().
--- drivers/net/can/usb/gs_usb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/can/usb/gs_usb.c +2 -0
@@ -246,6 +246,8 @@ static int gs_cmd_reset(struct gs_usb *gsizeof (*dm), 1000); +kfree (dm); +return rc; }
Greg Kroah-Hartman
maintainerPATCH 4/30 vb2: Fix an off by one error in vb2_plane_vaddr
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
commit 5ebb6dd36c9f5fb37b1077b393c254d70a14cb46 upstream.
We should ensure that 'plane_no' is '< vb->num_planes' as done in 'vb2_plane_cookie' just a few lines below.
--- drivers/media/v4l2-core/videobuf2-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/v4l2-core/videobuf2-core.c +1 -1
@@ -793,7 +793,7 @@ EXPORT_SYMBOL_GPL(vb2_core_create_bufs);*/ void *vb2_plane_vaddr (struct vb2_buffer *vb,unsigned int plane_no) { -if (plane_no > vb->num_planes || !vb->planes[plane_no].mem_priv) +if (plane_no >= vb->num_planes || !vb->planes[plane_no].mem_priv)return NULL ;return call_ptr_memop (vb, vaddr, vb->planes[plane_no].mem_priv);
Greg Kroah-Hartman
maintainerPATCH 5/30 mac80211: dont look at the PM bit of BAR frames
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emmanuel Grumbach <[email protected]>
commit 769dc04db3ed8484798aceb015b94deacc2ba557 upstream.
When a peer sends a BAR frame with PM bit clear, we should not modify its PM state as madated by the spec in 802.11-20012 10.2.1.2.
--- net/mac80211/rx.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/mac80211/rx.c +5 -1
@@ -1455,12 +1455,16 @@ ieee80211_rx_h_sta_process(struct ieee80*/ if (!ieee80211_hw_check (&sta->local->hw,AP_LINK_PS ) && !ieee80211_has_morefrags (hdr->frame_control) && + !ieee80211_is_back_req (hdr->frame_control) && !(status->rx_flags &IEEE80211_RX_DEFERRED_RELEASE ) && (rx->sdata->vif.type ==NL80211_IFTYPE_AP || rx->sdata->vif.type ==NL80211_IFTYPE_AP_VLAN ) && -/* PM bit is only checked in frames where it isn't reserved, +/* +* PM bit is only checked in frames where it isn't reserved, * in AP mode it's reserved in non-bufferable management frames * (cf. IEEE 802.11-2012 8.2.4.1.7 Power Management field) +* BAR frames should be ignored as specified in +* IEEE 802.11-2012 10.2.1.2. */ (!ieee80211_is_mgmt (hdr->frame_control) ||ieee80211_is_bufferable_mmpdu (hdr->frame_control))) {
Greg Kroah-Hartman
maintainerPATCH 6/30 mac80211/wpa: use constant time memory comparison for MACs
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason A. Donenfeld <[email protected]>
commit 98c67d187db7808b1f3c95f2110dd4392d034182 upstream.
Otherwise, we enable all sorts of forgeries via timing attack.
--- net/mac80211/wpa.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
net/mac80211/wpa.c +5 -4
@@ -16,6 +16,7 @@#include <asm/unaligned.h> #include <net/mac80211.h> #include <crypto/aes.h> +#include <crypto/algapi.h> #include "ieee80211_i.h" #include "michael.h"
@@ -152,7 +153,7 @@ ieee80211_rx_h_michael_mic_verify(struct data_len = skb->len - hdrlen -MICHAEL_MIC_LEN ; key = &rx->key->conf.key[NL80211_TKIP_DATA_OFFSET_RX_MIC_KEY ];michael_mic (key, hdr, data, data_len, mic); -if (memcmp (mic, data + data_len,MICHAEL_MIC_LEN ) !=0 ) +if (crypto_memneq (mic, data + data_len,MICHAEL_MIC_LEN )) goto mic_fail;/* remove Michael MIC from payload */
@@ -1044,7 +1045,7 @@ ieee80211_crypto_aes_cmac_decrypt(structbip_aad (skb, aad);ieee80211_aes_cmac (key->u.aes_cmac.tfm, aad, skb->data +24 , skb->len -24 , mic); -if (memcmp (mic, mmie->mic,sizeof (mmie->mic)) !=0 ) { +if (crypto_memneq (mic, mmie->mic,sizeof (mmie->mic))) { key->u.aes_cmac.icverrors++;return RX_DROP_UNUSABLE ; }
@@ -1094,7 +1095,7 @@ ieee80211_crypto_aes_cmac_256_decrypt(stbip_aad (skb, aad);ieee80211_aes_cmac_256 (key->u.aes_cmac.tfm, aad, skb->data +24 , skb->len -24 , mic); -if (memcmp (mic, mmie->mic,sizeof (mmie->mic)) !=0 ) { +if (crypto_memneq (mic, mmie->mic,sizeof (mmie->mic))) { key->u.aes_cmac.icverrors++;return RX_DROP_UNUSABLE ; }
@@ -1198,7 +1199,7 @@ ieee80211_crypto_aes_gmac_decrypt(structif (ieee80211_aes_gmac (key->u.aes_gmac.tfm, aad, nonce, skb->data +24 , skb->len -24 , mic) <0 || -memcmp (mic, mmie->mic,sizeof (mmie->mic)) !=0 ) { +crypto_memneq (mic, mmie->mic,sizeof (mmie->mic))) { key->u.aes_gmac.icverrors++;return RX_DROP_UNUSABLE ; }
Greg Kroah-Hartman
maintainerPATCH 8/30 mac80211: fix IBSS presp allocation size
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
commit f1f3e9e2a50a70de908f9dfe0d870e9cdc67e042 upstream.
When VHT IBSS support was added, the size of the extra elements wasn't considered in ieee80211_ibss_build_presp(), which makes it possible that it would overrun the allocated buffer. Fix it by allocating the necessary space.
--- net/mac80211/ibss.c | 2 ++ 1 file changed, 2 insertions(+)
net/mac80211/ibss.c +2 -0
@@ -66,6 +66,8 @@ ieee80211_ibss_build_presp(struct ieee802 + (IEEE80211_MAX_SUPP_RATES -8 ) +2 +sizeof (struct ieee80211_ht_cap ) +2 +sizeof (struct ieee80211_ht_operation ) + +2 +sizeof (struct ieee80211_vht_cap ) + +2 +sizeof (struct ieee80211_vht_operation ) + ifibss->ie_len; presp =kzalloc (sizeof (*presp) + frame_len,GFP_KERNEL );if (!presp)
Greg Kroah-Hartman
maintainerPATCH 10/30 x86/mm/32: Set the __vmalloc_start_set flag in initmem_init()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Laura Abbott <[email protected]>
commit 861ce4a3244c21b0af64f880d5bfe5e6e2fb9e4a upstream.
'__vmalloc_start_set' currently only gets set in initmem_init() when !CONFIG_NEED_MULTIPLE_NODES. This breaks detection of vmalloc address with virt_addr_valid() with CONFIG_NEED_MULTIPLE_NODES=y, causing a kernel crash:
[mm/usercopy] 517e1fbeb6: kernel BUG at arch/x86/mm/physaddr.c:78!
Set '__vmalloc_start_set' appropriately for that case as well.
--- arch/x86/mm/numa_32.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/mm/numa_32.c +1 -0
@@ -100,5 +100,6 @@ void __init initmem_init(void)printk (KERN_DEBUG "High memory starts at vaddr %08lx\n" , (ulong )pfn_to_kaddr (highstart_pfn)); + __vmalloc_start_set = true;setup_bootmem_allocator (); }
Greg Kroah-Hartman
maintainerPATCH 11/30 mfd: omap-usb-tll: Fix inverted bit use for USB TLL mode
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <[email protected]>
commit 8b8a84c54aff4256d592dc18346c65ecf6811b45 upstream.
Commit 16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver") added support for USB TLL, but uses OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF bit the wrong way. The comments in the code are correct, but the inverted use of OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF causes the register to be enabled instead of disabled unlike what the comments say.
Without this change the Wrigley 3G LTE modem on droid 4 EHCI bus can be only pinged few times before it stops responding.
--- drivers/mfd/omap-usb-tll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mfd/omap-usb-tll.c +1 -1
@@ -375,8 +375,8 @@ int omap_tll_init(struct usbhs_omap_plat* and use SDR Mode */ reg &= ~(OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE - |OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF |OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE ); + reg |=OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF ; }else if (pdata->port_mode[i] ==OMAP_EHCI_PORT_MODE_HSIC ) {/*
Greg Kroah-Hartman
maintainerPATCH 12/30 staging: rtl8188eu: prevent an underflow in rtw_check_beacon_data()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 784047eb2d3405a35087af70cba46170c5576b25 upstream.
The "len" could be as low as -14 so we should check for negatives.
--- drivers/staging/rtl8188eu/core/rtw_ap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/rtl8188eu/core/rtw_ap.c +1 -1
@@ -894,7 +894,7 @@ int rtw_check_beacon_data(struct adapterreturn _FAIL; -if (len >MAX_IE_SZ ) +if (len <0 || len >MAX_IE_SZ )return _FAIL; pbss_network->IELength = len;
Greg Kroah-Hartman
maintainerPATCH 13/30 iio: proximity: as3935: recalibrate RCO after resume
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matt Ranostay <[email protected]>
commit 6272c0de13abf1480f701d38288f28a11b4301c4 upstream.
According to the datasheet the RCO must be recalibrated on every power-on-reset. Also remove mutex locking in the calibration function since callers other than the probe function (which doesn't need it) will have a lock.
--- drivers/iio/proximity/as3935.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/iio/proximity/as3935.c +2 -4
@@ -263,8 +263,6 @@ static irqreturn_t as3935_interrupt_handstatic void calibrate_as3935 (struct as3935_state *st) { -mutex_lock (&st->lock); -/* mask disturber interrupt bit */ as3935_write (st,AS3935_INT ,BIT (5 ));
@@ -274,8 +272,6 @@ static void calibrate_as3935(struct as39mdelay (2 );as3935_write (st,AS3935_TUNE_CAP , (st->tune_cap /TUNE_CAP_DIV )); - -mutex_unlock (&st->lock); }#ifdef CONFIG_PM_SLEEP
@@ -312,6 +308,8 @@ static int as3935_resume(struct device * val &= ~AS3935_AFE_PWR_BIT ; ret =as3935_write (st,AS3935_AFE_GAIN , val); +calibrate_as3935 (st); + err_resume:mutex_unlock (&st->lock);
Greg Kroah-Hartman
maintainerPATCH 14/30 USB: hub: fix SS max number of ports
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit 93491ced3c87c94b12220dbac0527e1356702179 upstream.
Add define for the maximum number of ports on a SuperSpeed hub as per USB 3.1 spec Table 10-5, and use it when verifying the retrieved hub descriptor.
This specifically avoids benign attempts to update the DeviceRemovable mask for non-existing ports (should we get that far).
--- drivers/usb/core/hub.c | 8 +++++++- include/uapi/linux/usb/ch11.h | 3 +++ 2 files changed, 10 insertions(+), 1 deletion(-)
drivers/usb/core/hub.c +7 -1
@@ -1318,7 +1318,13 @@ static int hub_configure(struct usb_hubif (ret <0 ) { message ="can't read hub descriptor" ; goto fail; - }else if (hub->descriptor->bNbrPorts >USB_MAXCHILDREN ) { + } + + maxchild =USB_MAXCHILDREN ; +if (hub_is_superspeed (hdev)) + maxchild =min_t (unsigned, maxchild,USB_SS_MAXPORTS ); + +if (hub->descriptor->bNbrPorts > maxchild) { message ="hub has too many ports!" ; ret = -ENODEV ; goto fail;
include/uapi/linux/usb/ch11.h +3 -0
@@ -22,6 +22,9 @@*/ #define USB_MAXCHILDREN 31 +/* See USB 3.1 spec Table 10-5 */ +#define USB_SS_MAXPORTS 15 +/* * Hub request types */
Greg Kroah-Hartman
maintainerPATCH 15/30 usb: core: fix potential memory leak in error path during hcd creation
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Bondarenko <[email protected]>
commit 1a744d2eb76aaafb997fda004ae3ae62a1538f85 upstream.
Free memory allocated for address0_mutex if allocation of bandwidth_mutex failed.
--- drivers/usb/core/hcd.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/core/hcd.c +1 -0
@@ -2511,6 +2511,7 @@ struct usb_hcd *usb_create_shared_hcd(co hcd->bandwidth_mutex =kmalloc (sizeof (*hcd->bandwidth_mutex),GFP_KERNEL );if (!hcd->bandwidth_mutex) { +kfree (hcd->address0_mutex);kfree (hcd);dev_dbg (dev,"hcd bandwidth mutex alloc failed\n" );return NULL ;
Greg Kroah-Hartman
maintainerPATCH 16/30 pvrusb2: reduce stack usage pvr2_eeprom_analyze()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 6830733d53a4517588e56227b9c8538633f0c496 upstream.
The driver uses a relatively large data structure on the stack, which showed up on my radar as we get a warning with the "latent entropy" GCC plugin:
drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]
The warning is usually hidden as we raise the warning limit to 2048 when the plugin is enabled, but I'd like to lower that again in the future, and making this function smaller helps to do that without build regressions.
Further analysis shows that putting an 'i2c_client' structure on the stack is not really supported, as the embedded 'struct device' is not initialized here, and we are only saved by the fact that the function that is called here does not use the pointer at all.
--- drivers/media/usb/pvrusb2/pvrusb2-eeprom.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)
drivers/media/usb/pvrusb2/pvrusb2-eeprom.c +3 -8
@@ -123,15 +123,10 @@ int pvr2_eeprom_analyze(struct pvr2_hdwmemset (&tvdata,0 ,sizeof (tvdata)); eeprom =pvr2_eeprom_fetch (hdw); -if (!eeprom)return -EINVAL ; +if (!eeprom) +return -EINVAL ; - { -struct i2c_client fake_client; -/* Newer version expects a useless client interface */ - fake_client.addr = hdw->eeprom_addr; - fake_client.adapter = &hdw->i2c_adap; -tveeprom_hauppauge_analog (&fake_client,&tvdata,eeprom); - } +tveeprom_hauppauge_analog (NULL , &tvdata, eeprom);trace_eeprom ("eeprom assumed v4l tveeprom module" );trace_eeprom ("eeprom direct call results:" );
Re: [PATCH 4.4 16/30] [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()
Quoted 19 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit
6830733d53a4517588e56227b9c8538633f0c496upstream.The driver uses a relatively large data structure on the stack, which showed up on my radar as we get a warning with the "latent entropy" GCC plugin:
drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]The warning is usually hidden as we raise the warning limit to 2048 when the plugin is enabled, but I'd like to lower that again in the future, and making this function smaller helps to do that without build regressions.
Quoted 4 lines
Further analysis shows that putting an '
i2c_client' structure on the stack is not really supported, as the embedded 'struct device' is not initialized here, and we are only saved by the fact that the function that is called here does not use the pointer at all.
[...]
That is not true in 4.4-stable. This commit depends on:
commit 6037b3ca28f4258d913dbe77248fd77827702ae3
Author: Mauro Carvalho Chehab <[email protected]> Date: Wed Nov 16 14:21:48 2016 -0200
[media] tveeprom: print log messages using pr_foo()
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 16/30] [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()
Quoted 26 lines · Ben Hutchings
Quoted 23 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit
6830733d53a4517588e56227b9c8538633f0c496upstream.The driver uses a relatively large data structure on the stack, which showed up on my radar as we get a warning with the "latent entropy" GCC plugin:
drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]The warning is usually hidden as we raise the warning limit to 2048 when the plugin is enabled, but I'd like to lower that again in the future, and making this function smaller helps to do that without build regressions.
Further analysis shows that putting an '
i2c_client' structure on the stack is not really supported, as the embedded 'struct device' is not initialized here, and we are only saved by the fact that the function that is called here does not use the pointer at all.[...]
Quoted 7 lines
That is not true in 4.4-stable. This commit depends on:
commit
6037b3ca28f4258d913dbe77248fd77827702ae3Author: Mauro Carvalho Chehab <[email protected]> Date: Wed Nov 16 14:21:48 2016 -0200[media] tveeprom: print log messages using
pr_foo()
It does? I don't understand how the two are connected. Removing i2c_client off of the stack is a good thing. Ah, I see how the pointer is used in tveeprom_hauppauge_analog(), but this shouldn't matter here, right?
thanks,
greg k-h
Re: [PATCH 4.4 16/30] [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()
Quoted 31 lines · Greg Kroah-Hartman
Quoted 30 lines · Ben Hutchings
Quoted 17 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
From: Arnd Bergmann <[email protected]>
commit
6830733d53a4517588e56227b9c8538633f0c496upstream.The driver uses a relatively large data structure on the stack, which showed up on my radar as we get a warning with the "latent entropy" GCC plugin:
drivers/media/usb/pvrusb2/pvrusb2-eeprom.c:153:1: error: the frame size of 1376 bytes is larger than 1152 bytes [-Werror=frame-larger-than=]The warning is usually hidden as we raise the warning limit to 2048 when the plugin is enabled, but I'd like to lower that again in the future, and making this function smaller helps to do that without build regressions.
Quoted 4 lines
Further analysis shows that putting an '
i2c_client' structure on the stack is not really supported, as the embedded 'struct device' is not initialized here, and we are only saved by the fact that the function that is called here does not use the pointer at all.[...]
That is not true in 4.4-stable. This commit depends on:
commit
6037b3ca28f4258d913dbe77248fd77827702ae3Author: Mauro Carvalho Chehab <[email protected]> Date: Wed Nov 16 14:21:48 2016 -0200
Quoted 6 lines
Quoted 1 line
[media] tveeprom: print log messages using
pr_foo()It does? I don't understand how the two are connected. Removing
i2c_clientoff of the stack is a good thing. Ah, I see how the pointer is used intveeprom_hauppauge_analog(), but this shouldn't matter here, right?
My reading of the two patches is that we actually need at least one of them to avoid interpreting uninitialized dev->class/bus: With just my 6830733d53a patch, we replace the uninitialized data with a NULL pointer, which is handled gracefully in __dev_printk(), while the 6037b3ca28 patch by itself will avoid using the 'dev' pointer completely, and give a saner output (no "(NULL device)" string or worse).
I think we probably want both of them backported to 4.4, but I don't see a dependency between them.
Arnd
Re: [PATCH 4.4 16/30] [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · Greg Kroah-Hartman
Quoted 6 lines · Ben Hutchings
Quoted 5 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
From: Arnd Bergmann <[email protected]>
commit
6830733d53a4517588e56227b9c8538633f0c496upstream.
[...]
Quoted 26 lines
Quoted 12 lines
Quoted 12 lines
Quoted 4 lines
Further analysis shows that putting an '
i2c_client' structure on the stack is not really supported, as the embedded 'struct device' is not initialized here, and we are only saved by the fact that the function that is called here does not use the pointer at all.[...]
That is not true in 4.4-stable. This commit depends on:
commit
6037b3ca28f4258d913dbe77248fd77827702ae3Author: Mauro Carvalho Chehab <[email protected]> Date: Wed Nov 16 14:21:48 2016 -0200Quoted 6 lines
Quoted 1 line
[media] tveeprom: print log messages using
pr_foo()It does? I don't understand how the two are connected. Removing
i2c_clientoff of the stack is a good thing. Ah, I see how the pointer is used intveeprom_hauppauge_analog(), but this shouldn't matter here, right?My reading of the two patches is that we actually need at least one of them to avoid interpreting uninitialized dev->class/bus: With just my
6830733d53apatch, we replace the uninitialized data with a NULL pointer, which is handled gracefully in__dev_printk(), while the6037b3ca28patch by itself will avoid using the 'dev' pointer completely, and give a saner output (no "(NULL device)" string or worse).
Quoted 2 lines
I think we probably want both of them backported to 4.4, but I don't see a dependency between them.
Sorry, I mixed up two commits. The one actually needed to avoid a null dereference is:
commit 7cda4c5bae46ffca3abeadc4c1882d9325ee3102
Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Oct 13 10:51:20 2016 -0300
[media] tveeprom: use dev_foo() for printk messages
Then "[media] tveeprom: print log messages using pr_foo()" is cleanup on top of that.
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Re: [PATCH 4.4 16/30] [media] pvrusb2: reduce stack usage pvr2_eeprom_analyze()
Quoted 9 lines · Ben Hutchings
Quoted 4 lines · Arnd Bergmann
On Mon, Jul 3, 2017 at 9:31 AM, Greg Kroah-Hartman
I think we probably want both of them backported to 4.4, but I don't see a dependency between them.
Sorry, I mixed up two commits. The one actually needed to avoid a null dereference is:
Quoted 8 lines
commit
7cda4c5bae46ffca3abeadc4c1882d9325ee3102Author: Mauro Carvalho Chehab <[email protected]> Date: Thu Oct 13 10:51:20 2016 -0300[media] tveeprom: use
dev_foo()for printk messagesThen "[media] tveeprom: print log messages using
pr_foo()" is cleanup on top of that.
Ah, I see now. We do indeed need both of Mauro's patches before we can apply mine then.
Arnd
Greg Kroah-Hartman
maintainerPATCH 17/30 USB: gadget: dummy_hcd: fix hub-descriptor removable fields
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <[email protected]>
commit d81182ce30dbd497a1e7047d7fda2af040347790 upstream.
Flag the first and only port as removable while also leaving the remaining bits (including the reserved bit zero) unset in accordance with the specifications:
"Within a byte, if no port exists for a given location, the bit field representing the port characteristics shall be 0."
Also add a comment marking the legacy PortPwrCtrlMask field.
--- drivers/usb/gadget/udc/dummy_hcd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/usb/gadget/udc/dummy_hcd.c +3 -3
@@ -2011,7 +2011,7 @@ ss_hub_descriptor(struct usb_hub_descrip HUB_CHAR_COMMON_OCPM); desc->bNbrPorts =1 ; desc->u.ss.bHubHdrDecLat =0x04 ;/* Worst case: 0.4 micro sec*/ - desc->u.ss.DeviceRemovable =0xffff ; + desc->u.ss.DeviceRemovable =0 ; }static inline void hub_descriptor (struct usb_hub_descriptor *desc)
@@ -2023,8 +2023,8 @@ static inline void hub_descriptor(structHUB_CHAR_INDV_PORT_LPSM | HUB_CHAR_COMMON_OCPM); desc->bNbrPorts =1 ; - desc->u.hs.DeviceRemovable[0 ] =0xff ; - desc->u.hs.DeviceRemovable[1 ] =0xff ; + desc->u.hs.DeviceRemovable[0 ] =0 ; + desc->u.hs.DeviceRemovable[1 ] =0xff ;/* PortPwrCtrlMask */ } static int dummy_hub_control(
Greg Kroah-Hartman
maintainerPATCH 18/30 usb: r8a66597-hcd: select a different endpoint on timeout
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Brandt <[email protected]>
commit 1f873d857b6c2fefb4dada952674aa01bcfb92bd upstream.
If multiple endpoints on a single device have pending IN URBs and one endpoint times out due to NAKs (perfectly legal), select a different endpoint URB to try.
The existing code only checked to see another device address has pending URBs and ignores other IN endpoints on the current device address. This leads to endpoints never getting serviced if one endpoint is using NAK as a flow control method.
--- drivers/usb/host/r8a66597-hcd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/host/r8a66597-hcd.c +3 -1
@@ -1785,6 +1785,7 @@ static void r8a66597_td_timer(unsigned l pipe = td->pipe;pipe_stop (r8a66597, pipe); +/* Select a different address or endpoint */ new_td = td; do { list_move_tail(&new_td->queue,
@@ -1794,7 +1795,8 @@ static void r8a66597_td_timer(unsigned l new_td = td;break ; } - }while (td != new_td && td->address == new_td->address); + }while (td != new_td && td->address == new_td->address && + td->pipe->info.epnum == new_td->pipe->info.epnum);start_transfer (r8a66597, new_td);
Greg Kroah-Hartman
maintainerPATCH 19/30 usb: r8a66597-hcd: decrease timeout
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Brandt <[email protected]>
commit dd14a3e9b92ac6f0918054f9e3477438760a4fa6 upstream.
The timeout for BULK packets was 300ms which is a long time if other endpoints or devices are waiting for their turn. Changing it to 50ms greatly increased the overall performance for multi-endpoint devices.
--- drivers/usb/host/r8a66597-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/r8a66597-hcd.c +1 -1
@@ -1269,7 +1269,7 @@ static void set_td_timer(struct r8a66597 time =30 ;break ;default : - time =300 ; + time =50 ;break ; }
Greg Kroah-Hartman
maintainerPATCH 20/30 drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 8128a31eaadbcdfa37774bbd28f3f00bac69996a upstream.
c2port_device_register() never returns NULL, it uses error pointers.
--- drivers/misc/c2port/c2port-duramar2150.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/misc/c2port/c2port-duramar2150.c +2 -2
@@ -129,8 +129,8 @@ static int __init duramar2150_c2port_ini duramar2150_c2port_dev =c2port_device_register ("uc" , &duramar2150_c2port_ops,NULL ); -if (!duramar2150_c2port_dev) { - ret = -ENODEV ; +if (IS_ERR (duramar2150_c2port_dev)) { + ret =PTR_ERR (duramar2150_c2port_dev); goto free_region; }
Greg Kroah-Hartman
maintainerPATCH 21/30 usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Corentin Labbe <[email protected]>
commit d2f48f05cd2a2a0a708fbfa45f1a00a87660d937 upstream.
When plugging an USB webcam I see the following message:
[106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [106390.583860] handle_tx_event: 913 callbacks suppressed
With this patch applied, I get no more printing of this message.
--- drivers/usb/host/xhci-pci.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/host/xhci-pci.c +3 -0
@@ -198,6 +198,9 @@ static void xhci_pci_quirks(struct devicif (pdev->vendor ==PCI_VENDOR_ID_ASMEDIA && pdev->device ==0x1042 ) xhci->quirks |=XHCI_BROKEN_STREAMS ; +if (pdev->vendor ==PCI_VENDOR_ID_ASMEDIA && + pdev->device ==0x1142 ) + xhci->quirks |=XHCI_TRUST_TX_LENGTH ;if (xhci->quirks &XHCI_RESET_ON_RESUME ) xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
Greg Kroah-Hartman
maintainerPATCH 22/30 USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit f16443a034c7aa359ddf6f0f9bc40d01ca31faea upstream.
Using the syzkaller kernel fuzzer, Andrey Konovalov generated the following error in gadgetfs:
Quoted 101 lines
BUG: KASAN: use-after-free in __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246 Read of size 8 at addr ffff88003a2bdaf8 by task kworker/3:1/903 CPU: 3 PID: 903 Comm: kworker/3:1 Not tainted 4.12.0-rc4+ #35 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x292/0x395 lib/dump_stack.c:52 print_address_description+0x78/0x280 mm/kasan/report.c:252 kasan_report_error mm/kasan/report.c:351 [inline] kasan_report+0x230/0x340 mm/kasan/report.c:408 __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:429 __lock_acquire+0x3069/0x3690 kernel/locking/lockdep.c:3246 lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:151 spin_lock include/linux/spinlock.h:299 [inline] gadgetfs_suspend+0x89/0x130 drivers/usb/gadget/legacy/inode.c:1682 set_link_state+0x88e/0xae0 drivers/usb/gadget/udc/dummy_hcd.c:455 dummy_hub_control+0xd7e/0x1fb0 drivers/usb/gadget/udc/dummy_hcd.c:2074 rh_call_control drivers/usb/core/hcd.c:689 [inline] rh_urb_enqueue drivers/usb/core/hcd.c:846 [inline] usb_hcd_submit_urb+0x92f/0x20b0 drivers/usb/core/hcd.c:1650 usb_submit_urb+0x8b2/0x12c0 drivers/usb/core/urb.c:542 usb_start_wait_urb+0x148/0x5b0 drivers/usb/core/message.c:56 usb_internal_control_msg drivers/usb/core/message.c:100 [inline] usb_control_msg+0x341/0x4d0 drivers/usb/core/message.c:151 usb_clear_port_feature+0x74/0xa0 drivers/usb/core/hub.c:412 hub_port_disable+0x123/0x510 drivers/usb/core/hub.c:4177 hub_port_init+0x1ed/0x2940 drivers/usb/core/hub.c:4648 hub_port_connect drivers/usb/core/hub.c:4826 [inline] hub_port_connect_change drivers/usb/core/hub.c:4999 [inline] port_event drivers/usb/core/hub.c:5105 [inline] hub_event+0x1ae1/0x3d40 drivers/usb/core/hub.c:5185 process_one_work+0xc08/0x1bd0 kernel/workqueue.c:2097 process_scheduled_works kernel/workqueue.c:2157 [inline] worker_thread+0xb2b/0x1860 kernel/workqueue.c:2233 kthread+0x363/0x440 kernel/kthread.c:231 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:424 Allocated by task 9958: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:513 set_track mm/kasan/kasan.c:525 [inline] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:617 kmem_cache_alloc_trace+0x87/0x280 mm/slub.c:2745 kmalloc include/linux/slab.h:492 [inline] kzalloc include/linux/slab.h:665 [inline] dev_new drivers/usb/gadget/legacy/inode.c:170 [inline] gadgetfs_fill_super+0x24f/0x540 drivers/usb/gadget/legacy/inode.c:1993 mount_single+0xf6/0x160 fs/super.c:1192 gadgetfs_mount+0x31/0x40 drivers/usb/gadget/legacy/inode.c:2019 mount_fs+0x9c/0x2d0 fs/super.c:1223 vfs_kern_mount.part.25+0xcb/0x490 fs/namespace.c:976 vfs_kern_mount fs/namespace.c:2509 [inline] do_new_mount fs/namespace.c:2512 [inline] do_mount+0x41b/0x2d90 fs/namespace.c:2834 SYSC_mount fs/namespace.c:3050 [inline] SyS_mount+0xb0/0x120 fs/namespace.c:3027 entry_SYSCALL_64_fastpath+0x1f/0xbe Freed by task 9960: save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59 save_stack+0x43/0xd0 mm/kasan/kasan.c:513 set_track mm/kasan/kasan.c:525 [inline] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:590 slab_free_hook mm/slub.c:1357 [inline] slab_free_freelist_hook mm/slub.c:1379 [inline] slab_free mm/slub.c:2961 [inline] kfree+0xed/0x2b0 mm/slub.c:3882 put_dev+0x124/0x160 drivers/usb/gadget/legacy/inode.c:163 gadgetfs_kill_sb+0x33/0x60 drivers/usb/gadget/legacy/inode.c:2027 deactivate_locked_super+0x8d/0xd0 fs/super.c:309 deactivate_super+0x21e/0x310 fs/super.c:340 cleanup_mnt+0xb7/0x150 fs/namespace.c:1112 __cleanup_mnt+0x1b/0x20 fs/namespace.c:1119 task_work_run+0x1a0/0x280 kernel/task_work.c:116 exit_task_work include/linux/task_work.h:21 [inline] do_exit+0x18a8/0x2820 kernel/exit.c:878 do_group_exit+0x14e/0x420 kernel/exit.c:982 get_signal+0x784/0x1780 kernel/signal.c:2318 do_signal+0xd7/0x2130 arch/x86/kernel/signal.c:808 exit_to_usermode_loop+0x1ac/0x240 arch/x86/entry/common.c:157 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath+0x3ba/0x410 arch/x86/entry/common.c:263 entry_SYSCALL_64_fastpath+0xbc/0xbe The buggy address belongs to the object at ffff88003a2bdae0 which belongs to the cache kmalloc-1024 of size 1024 The buggy address is located 24 bytes inside of 1024-byte region [ffff88003a2bdae0, ffff88003a2bdee0) The buggy address belongs to the page: page:ffffea0000e8ae00 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x100000000008100(slab|head) raw: 0100000000008100 0000000000000000 0000000000000000 0000000100170017 raw: ffffea0000ed3020 ffffea0000f5f820 ffff88003e80efc0 0000000000000000 page dumped because: kasan: bad access detected
Quoted 8 lines
Memory state around the buggy address:
ffff88003a2bd980: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88003a2bda00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88003a2bda80: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fb
^
ffff88003a2bdb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88003a2bdb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================What this means is that the gadgetfs_suspend() routine was trying to access dev->lock after it had been deallocated. The root cause is a race in the dummy_hcd driver; the dummy_udc_stop() routine can race with the rest of the driver because it contains no locking. And even when proper locking is added, it can still race with the set_link_state() function because that function incorrectly drops the private spinlock before invoking any gadget driver callbacks.
The result of this race, as seen above, is that set_link_state() can invoke a callback in gadgetfs even after gadgetfs has been unbound from dummy_hcd's UDC and its private data structures have been deallocated.
include/linux/usb/gadget.h documents that the ->reset, ->disconnect, ->suspend, and ->resume callbacks may be invoked in interrupt context. In general this is necessary, to prevent races with gadget driver removal. This patch fixes dummy_hcd to retain the spinlock across these calls, and it adds a spinlock acquisition to dummy_udc_stop() to prevent the race.
The net2280 driver makes the same mistake of dropping the private spinlock for its ->disconnect and ->reset callback invocations. The patch fixes it too.
Lastly, since gadgetfs_suspend() may be invoked in interrupt context, it cannot assume that interrupts are enabled when it runs. It must use spin_lock_irqsave() instead of spin_lock_irq(). The patch fixes that bug as well.
--- drivers/usb/gadget/legacy/inode.c | 5 +++-- drivers/usb/gadget/udc/dummy_hcd.c | 13 ++++--------- drivers/usb/gadget/udc/net2280.c | 9 +-------- 3 files changed, 8 insertions(+), 19 deletions(-)
drivers/usb/gadget/legacy/inode.c +3 -2
@@ -1676,9 +1676,10 @@ static void gadgetfs_suspend (struct usb_gadget *gadget) {struct dev_data *dev =get_gadget_data (gadget); +unsigned long flags;INFO (dev,"suspended from state %d\n" , dev->state); -spin_lock (&dev->lock); +spin_lock_irqsave (&dev->lock, flags);switch (dev->state) {case STATE_DEV_SETUP :// VERY odd... host died?? case STATE_DEV_CONNECTED :
@@ -1689,7 +1690,7 @@ gadgetfs_suspend (struct usb_gadget *gaddefault :break ; } -spin_unlock (&dev->lock); +spin_unlock_irqrestore (&dev->lock, flags); }static struct usb_gadget_driver gadgetfs_driver = {
drivers/usb/gadget/udc/dummy_hcd.c +4 -9
@@ -442,23 +442,16 @@ static void set_link_state(struct dummy_/* Report reset and disconnect events to the driver */ if (dum->driver && (disconnect || reset)) {stop_activity (dum); -spin_unlock (&dum->lock);if (reset)usb_gadget_udc_reset (&dum->gadget, dum->driver);else dum->driver->disconnect (&dum->gadget); -spin_lock (&dum->lock); } }else if (dum_hcd->active != dum_hcd->old_active) { -if (dum_hcd->old_active && dum->driver->suspend) { -spin_unlock (&dum->lock); +if (dum_hcd->old_active && dum->driver->suspend) dum->driver->suspend (&dum->gadget); -spin_lock (&dum->lock); - }else if (!dum_hcd->old_active && dum->driver->resume) { -spin_unlock (&dum->lock); +else if (!dum_hcd->old_active && dum->driver->resume) dum->driver->resume (&dum->gadget); -spin_lock (&dum->lock); - } } dum_hcd->old_status = dum_hcd->port_status;
@@ -985,7 +978,9 @@ static int dummy_udc_stop(struct usb_gadstruct dummy_hcd *dum_hcd =gadget_to_dummy_hcd (g);struct dummy *dum = dum_hcd->dum; +spin_lock_irq (&dum->lock); dum->driver =NULL ; +spin_unlock_irq (&dum->lock);return 0 ; }
drivers/usb/gadget/udc/net2280.c +1 -8
@@ -2425,11 +2425,8 @@ static void stop_activity(struct net2280nuke (&dev->ep[i]);/* report disconnect; the driver is already quiesced */ -if (driver) { -spin_unlock (&dev->lock); +if (driver) driver->disconnect (&dev->gadget); -spin_lock (&dev->lock); - }usb_reinit (dev); }
@@ -3275,8 +3272,6 @@ next_endpoints: BIT(PCI_RETRY_ABORT_INTERRUPT))static void handle_stat1_irqs (struct net2280 *dev,u32 stat) -__releases(dev->lock) -__acquires(dev->lock) {struct net2280_ep *ep;u32 tmp, num, mask, scratch;
@@ -3317,14 +3312,12 @@ __acquires(dev->lock)if (disconnect || reset) {stop_activity (dev, dev->driver);ep0_start (dev); -spin_unlock (&dev->lock);if (reset)usb_gadget_udc_reset (&dev->gadget, dev->driver);else (dev->driver->disconnect) (&dev->gadget); -spin_lock (&dev->lock);return ; } }
Re: [PATCH 4.4 22/30] USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit
f16443a034c7aa359ddf6f0f9bc40d01ca31faeaupstream.
[...]
Quoted 12 lines
The result of this race, as seen above, is that
set_link_state()can invoke a callback in gadgetfs even after gadgetfs has been unbound from dummy_hcd's UDC and its private data structures have been deallocated.
include/linux/usb/gadget.hdocuments that the ->reset, ->disconnect, ->suspend, and ->resume callbacks may be invoked in interrupt context. In general this is necessary, to prevent races with gadget driver removal. This patch fixesdummy_hcdto retain the spinlock across these calls, and it adds a spinlock acquisition todummy_udc_stop()to prevent the race.
Quoted 3 lines
The net2280 driver makes the same mistake of dropping the private spinlock for its ->disconnect and ->reset callback invocations. The patch fixes it too.
[...]
Why only these two drivers? Most of the other UDC drivers seem to do the same thing.
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Re: [PATCH 4.4 22/30] USB: gadgetfs, dummy-hcd, net2280: fix locking for callbacks
Quoted 21 lines · Ben Hutchings
Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit
f16443a034c7aa359ddf6f0f9bc40d01ca31faeaupstream.[...]
Quoted 12 lines
The result of this race, as seen above, is that
set_link_state()can invoke a callback in gadgetfs even after gadgetfs has been unbound from dummy_hcd's UDC and its private data structures have been deallocated.
include/linux/usb/gadget.hdocuments that the ->reset, ->disconnect, ->suspend, and ->resume callbacks may be invoked in interrupt context. In general this is necessary, to prevent races with gadget driver removal. This patch fixesdummy_hcdto retain the spinlock across these calls, and it adds a spinlock acquisition todummy_udc_stop()to prevent the race.
Quoted 7 lines
Quoted 3 lines
The net2280 driver makes the same mistake of dropping the private spinlock for its ->disconnect and ->reset callback invocations. The patch fixes it too.
[...]
Why only these two drivers? Most of the other UDC drivers seem to do the same thing.
I'm not at all familiar with the other UDC drivers, only those two.
If the maintainers for other UDC drivers would like to discuss the problem and consider whether changes are needed, I'd be glad to help.
Alan Stern
Greg Kroah-Hartman
maintainerPATCH 23/30 mm/memory-failure.c: use compound_head() flags for huge pages
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <[email protected]>
commit 7258ae5c5a2ce2f5969e8b18b881be40ab55433d upstream.
memory_failure() chooses a recovery action function based on the page flags. For huge pages it uses the tail page flags which don't have anything interesting set, resulting in:
Quoted 2 lines
Memory failure:
0x9be3b4: Unknown page state
Memory failure:0x9be3b4: recovery action for unknown page: Failed
Instead, save a copy of the head page's flags if this is a huge page, this means if there are no relevant flags for this tail page, we use the head pages flags instead. This results in the me_huge_page() recovery action being called:
Quoted 1 line
Memory failure:
0x9b7969: recovery action for huge page: Delayed
For hugepages that have not yet been allocated, this allows the hugepage to be dequeued.
--- mm/memory-failure.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
mm/memory-failure.c +4 -1
@@ -1208,7 +1208,10 @@ int memory_failure(unsigned long pfn, in* page_remove_rmap() in try_to_unmap_one(). So to determine page status * correctly, we save a copy of the page flags at this time. */ - page_flags = p->flags; +if (PageHuge (p)) + page_flags = hpage->flags; +else + page_flags = p->flags;/* * unpoison always clear PG_hwpoison inside page lock
Greg Kroah-Hartman
maintainerPATCH 24/30 swap: cond_resched in swap_cgroup_prepare()
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Zhao <[email protected]>
commit ef70762948dde012146926720b70e79736336764 upstream.
I saw need_resched() warnings when swapping on large swapfile (TBs) because continuously allocating many pages in swap_cgroup_prepare() took too long.
We already cond_resched when freeing page in swap_cgroup_swapoff(). Do the same for the page allocation.
--- mm/swap_cgroup.c | 3 +++ 1 file changed, 3 insertions(+)
mm/swap_cgroup.c +3 -0
@@ -48,6 +48,9 @@ static int swap_cgroup_prepare(int type)if (!page) goto not_enough_page; ctrl->map[idx] = page; + +if (!(idx %SWAP_CLUSTER_MAX )) +cond_resched (); }return 0 ; not_enough_page:
Re: [PATCH 4.4 24/30] swap: cond_resched in swap_cgroup_prepare()
Quoted 6 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Zhao <[email protected]>
Quoted 8 lines
commit
ef70762948dde012146926720b70e79736336764upstream.I saw
need_resched()warnings when swapping on large swapfile (TBs) because continuously allocating many pages inswap_cgroup_prepare()took too long.We already
cond_reschedwhen freeing page inswap_cgroup_swapoff(). Do the same for the page allocation.
[...]
That seems to imply that this should also go into stable branches:
commit 460bcec84e11c75122ace5976214abbc596eb91b
Author: David Rientjes <[email protected]> Date: Fri Apr 7 16:05:00 2017 -0700
mm, swap_cgroup: reschedule when neeed in swap_cgroup_swapoff()
Ben.
Signature · 2 lines
Ben Hutchings Software Developer, Codethink Ltd.
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 24/30] swap: cond_resched in swap_cgroup_prepare()
Quoted 17 lines · Ben Hutchings
Quoted 14 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Zhao <[email protected]>
commit
ef70762948dde012146926720b70e79736336764upstream.I saw
need_resched()warnings when swapping on large swapfile (TBs) because continuously allocating many pages inswap_cgroup_prepare()took too long.We already
cond_reschedwhen freeing page inswap_cgroup_swapoff(). Do the same for the page allocation.[...]
Quoted 8 lines
That seems to imply that this should also go into stable branches:
commit
460bcec84e11c75122ace5976214abbc596eb91bAuthor: David Rientjes <[email protected]> Date: Fri Apr 7 16:05:00 2017 -0700mm,
swap_cgroup: reschedule when neeed inswap_cgroup_swapoff()
Looks like it to me, thanks, now queued up.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 25/30 genirq: Release resources in __setup_irq() error path
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
commit fa07ab72cbb0d843429e61bf179308aed6cbe0dd upstream.
In case __irq_set_trigger() fails the resources requested via irq_request_resources() are not released.
Add the missing release call into the error handling path.
--- kernel/irq/manage.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
kernel/irq/manage.c +3 -1
@@ -1287,8 +1287,10 @@ __setup_irq(unsigned int irq, struct irq ret =__irq_set_trigger (desc, new->flags &IRQF_TRIGGER_MASK ); -if (ret) +if (ret) { +irq_release_resources (desc); goto out_mask; + } } desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
Greg Kroah-Hartman
maintainerPATCH 26/30 alarmtimer: Prevent overflow of relative timers
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit f4781e76f90df7aec400635d73ea4c35ee1d4765 upstream.
Andrey reported a alartimer related RCU stall while fuzzing the kernel with syzkaller.
The reason for this is an overflow in ktime_add() which brings the resulting time into negative space and causes immediate expiry of the timer. The following rearm with a small interval does not bring the timer back into positive space due to the same issue.
This results in a permanent firing alarmtimer which hogs the CPU.
Use ktime_add_safe() instead which detects the overflow and clamps the result to KTIME_SEC_MAX.
--- kernel/time/alarmtimer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
kernel/time/alarmtimer.c +3 -3
@@ -339,7 +339,7 @@ void alarm_start_relative(struct alarm * {struct alarm_base *base = &alarm_bases[alarm->type]; - start =ktime_add (start, base->gettime ()); + start =ktime_add_safe (start, base->gettime ());alarm_start (alarm, start); }EXPORT_SYMBOL_GPL (alarm_start_relative);
@@ -425,7 +425,7 @@ u64 alarm_forward(struct alarm *alarm, k overrun++; } - alarm->node.expires =ktime_add (alarm->node.expires, interval); + alarm->node.expires =ktime_add_safe (alarm->node.expires, interval);return overrun; }EXPORT_SYMBOL_GPL (alarm_forward);
@@ -617,7 +617,7 @@ static int alarm_timer_set(struct k_itimktime_t now; now = alarm_bases[timr->it.alarm.alarmtimer.type].gettime (); - exp =ktime_add (now, exp); + exp =ktime_add_safe (now, exp); }alarm_start (&timr->it.alarm.alarmtimer, exp);
Greg Kroah-Hartman
maintainerPATCH 27/30 usb: dwc3: exynos fix axius clock error path to do cleanup
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuah Khan <[email protected]>
commit 8ae584d1951f241efd45499f8774fd7066f22823 upstream.
Axius clock error path returns without disabling clock and suspend clock. Fix it to disable them before returning error.
--- drivers/usb/dwc3/dwc3-exynos.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/usb/dwc3/dwc3-exynos.c +3 -1
@@ -148,7 +148,8 @@ static int dwc3_exynos_probe(struct plat exynos->axius_clk =devm_clk_get (dev,"usbdrd30_axius_clk" );if (IS_ERR (exynos->axius_clk)) {dev_err (dev,"no AXI UpScaler clk specified\n" ); -return -ENODEV ; + ret = -ENODEV ; + goto axius_clk_err; }clk_prepare_enable (exynos->axius_clk); }else {
@@ -206,6 +207,7 @@ err3:regulator_disable (exynos->vdd33); err2:clk_disable_unprepare (exynos->axius_clk); +axius_clk_err:clk_disable_unprepare (exynos->susp_clk);clk_disable_unprepare (exynos->clk);return ret;
Greg Kroah-Hartman
maintainerPATCH 28/30 MIPS: Fix bnezc/jialc return address calculation
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Burton <[email protected]>
commit 1a73d9310e093fc3adffba4d0a67b9fab2ee3f63 upstream.
The code handling the pop76 opcode (ie. bnezc & jialc instructions) in __compute_return_epc_for_insn() needs to set the value of $31 in the jialc case, which is encoded with rs = 0. However its check to differentiate bnezc (rs != 0) from jialc (rs = 0) was unfortunately backwards, meaning that if we emulate a bnezc instruction we clobber $31 & if we emulate a jialc instruction it actually behaves like a jic instruction.
Fix this by inverting the check of rs to match the way the instructions are actually encoded.
Patchwork: https://patchwork.linux-mips.org/patch/16178/
--- arch/mips/kernel/branch.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/mips/kernel/branch.c +3 -1
@@ -816,8 +816,10 @@ int __compute_return_epc_for_insn(struct break; }/* Compact branch: BNEZC || JIALC */ -if (insn.i_format.rs) +if (!insn.i_format.rs) { +/* JIALC: set $31/ra */ regs->regs[31 ] = epc +4 ; + } regs->cp0_epc +=8 ;break ;#endif
Greg Kroah-Hartman
maintainerPATCH 29/30 alarmtimer: Rate limit periodic intervals
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit ff86bf0c65f14346bf2440534f9ba5ac232c39a0 upstream.
The alarmtimer code has another source of potentially rearming itself too fast. Interval timers with a very samll interval have a similar CPU hog effect as the previously fixed overflow issue.
The reason is that alarmtimers do not implement the normal protection against this kind of problem which the other posix timer use:
timer expires -> queue signal -> deliver signal -> rearm timer
This scheme brings the rearming under scheduler control and prevents permanently firing timers which hog the CPU.
Bringing this scheme to the alarm timer code is a major overhaul because it lacks all the necessary mechanisms completely.
So for a quick fix limit the interval to one jiffie. This is not problematic in practice as alarmtimers are usually backed by an RTC for suspend which have 1 second resolution. It could be therefor argued that the resolution of this clock should be set to 1 second in general, but that's outside the scope of this fix.
--- kernel/time/alarmtimer.c | 8 ++++++++ 1 file changed, 8 insertions(+)
kernel/time/alarmtimer.c +8 -0
@@ -611,6 +611,14 @@ static int alarm_timer_set(struct k_itim/* start the timer */ timr->it.alarm.interval =timespec_to_ktime (new_setting->it_interval); + +/* +* Rate limit to the tick as a hot fix to prevent DOS. Will be +* mopped up later. +*/ +if (ktime_to_ns (timr->it.alarm.interval) <TICK_NSEC ) + timr->it.alarm.interval =ktime_set (0 ,TICK_NSEC ); + exp =timespec_to_ktime (new_setting->it_value);/* Convert (if necessary) to absolute time */ if (flags !=TIMER_ABSTIME ) {
Greg Kroah-Hartman
maintainerPATCH 30/30 mm: larger stack guard gap, between vmas
In reply to Greg Kroah-Hartman4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugh Dickins <[email protected]>
commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream.
Stack guard page is a useful feature to reduce a risk of stack smashing into a different mapping. We have been using a single page gap which is sufficient to prevent having stack adjacent to a different mapping. But this seems to be insufficient in the light of the stack usage in userspace. E.g. glibc uses as large as 64kB alloca() in many commonly used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX] which is 256kB or stack strings with MAX_ARG_STRLEN.
This will become especially dangerous for suid binaries and the default no limit for the stack size limit because those applications can be tricked to consume a large portion of the stack and a single glibc call could jump over the guard page. These attacks are not theoretical, unfortunatelly.
Make those attacks less probable by increasing the stack guard gap to 1MB (on systems with 4k pages; but make it depend on the page size because systems with larger base pages might cap stack allocations in the PAGE_SIZE units) which should cover larger alloca() and VLA stack allocations. It is obviously not a full fix because the problem is somehow inherent, but it should reduce attack space a lot.
One could argue that the gap size should be configurable from userspace, but that can be done later when somebody finds that the new 1MB is wrong for some special case applications. For now, add a kernel command line option (stack_guard_gap) to specify the stack gap size (in page units).
Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a stack vma, accounting a larger gap can break userspace - case in point, a program run with "ulimit -S -v 20000" failed when the 1MB gap was counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK and strict non-overcommit mode.
Instead of keeping gap inside the stack vma, maintain the stack guard gap as a gap between vmas: using vm_start_gap() in place of vm_start (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few places which need to respect the gap - mainly arch_get_unmapped_area(), and and the vma tree's subtree_gap support for that.
--- Documentation/kernel-parameters.txt | 7 + arch/arc/mm/mmap.c | 2 arch/arm/mm/mmap.c | 4 arch/frv/mm/elf-fdpic.c | 2 arch/mips/mm/mmap.c | 2 arch/parisc/kernel/sys_parisc.c | 15 ++- arch/powerpc/mm/slice.c | 2 arch/s390/mm/mmap.c | 4 arch/sh/mm/mmap.c | 4 arch/sparc/kernel/sys_sparc_64.c | 4 arch/sparc/mm/hugetlbpage.c | 2 arch/tile/mm/hugetlbpage.c | 2 arch/x86/kernel/sys_x86_64.c | 4 arch/x86/mm/hugetlbpage.c | 2 arch/xtensa/kernel/syscall.c | 2 fs/hugetlbfs/inode.c | 2 fs/proc/task_mmu.c | 4 include/linux/mm.h | 55 ++++++------- mm/gup.c | 5 - mm/memory.c | 38 --------- mm/mmap.c | 147 +++++++++++++++++++++--------------- 21 files changed, 148 insertions(+), 161 deletions(-)
Documentation/kernel-parameters.txt +7 -0
@@ -3580,6 +3580,13 @@ bytes respectively. Such letter suffixes spia_pedr= spia_peddr= + stack_guard_gap= [MM] + override the default stack gap protection. The value + is in page units and it defines how many pages prior + to (for stacks growing down) resp. after (for stacks + growing up) the main stack are reserved for no other + mapping. Default value is 256 pages. + stacktrace [FTRACE] Enabled the stack tracer on boot up.
arch/arc/mm/mmap.c +1 -1
@@ -64,7 +64,7 @@ arch_get_unmapped_area(struct file *filp vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
arch/arm/mm/mmap.c +2 -2
@@ -89,7 +89,7 @@ arch_get_unmapped_area(struct file *filp vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
@@ -140,7 +140,7 @@ arch_get_unmapped_area_topdown(struct fi addr =PAGE_ALIGN (addr); vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
arch/frv/mm/elf-fdpic.c +1 -1
@@ -74,7 +74,7 @@ unsigned long arch_get_unmapped_area(str addr =PAGE_ALIGN (addr); vma =find_vma (current->mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma))) goto success; }
arch/mips/mm/mmap.c +1 -1
@@ -92,7 +92,7 @@ static unsigned long arch_get_unmapped_a vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
arch/parisc/kernel/sys_parisc.c +9 -6
@@ -88,7 +88,7 @@ unsigned long arch_get_unmapped_area(str unsigned long len, unsigned long pgoff, unsigned long flags) { struct mm_struct *mm = current->mm; -struct vm_area_struct *vma; +struct vm_area_struct *vma, *prev;unsigned long task_size =TASK_SIZE ;int do_color_align, last_mmap;struct vm_unmapped_area_info info;
@@ -115,9 +115,10 @@ unsigned long arch_get_unmapped_area(strelse addr =PAGE_ALIGN (addr); - vma =find_vma (mm, addr); + vma =find_vma_prev (mm, addr, &prev);if (task_size - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)) && + (!prev || addr >=vm_end_gap (prev))) goto found_addr; }
@@ -141,7 +142,7 @@ arch_get_unmapped_area_topdown(struct fi const unsigned long len, const unsigned long pgoff, const unsigned long flags) { - struct vm_area_struct *vma; + struct vm_area_struct *vma, *prev;struct mm_struct *mm = current->mm;unsigned long addr = addr0;int do_color_align, last_mmap;
@@ -175,9 +176,11 @@ arch_get_unmapped_area_topdown(struct fi addr =COLOR_ALIGN (addr, last_mmap, pgoff); else addr =PAGE_ALIGN (addr); - vma =find_vma (mm, addr); + + vma =find_vma_prev (mm, addr, &prev);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)) && + (!prev || addr >=vm_end_gap (prev))) goto found_addr; }
arch/powerpc/mm/slice.c +1 -1
@@ -105,7 +105,7 @@ static int slice_area_is_free(struct mm_if ((mm->task_size - len) < addr)return 0 ; vma =find_vma (mm, addr); -return (!vma || (addr + len) <= vma->vm_start); +return (!vma || (addr + len) <=vm_start_gap (vma)); }static int slice_low_has_vma (struct mm_struct *mm,unsigned long slice)
arch/s390/mm/mmap.c +2 -2
@@ -97,7 +97,7 @@ arch_get_unmapped_area(struct file *filp addr =PAGE_ALIGN (addr); vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && addr >= mmap_min_addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
@@ -135,7 +135,7 @@ arch_get_unmapped_area_topdown(struct fi addr =PAGE_ALIGN (addr); vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && addr >= mmap_min_addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
arch/sh/mm/mmap.c +2 -2
@@ -63,7 +63,7 @@ unsigned long arch_get_unmapped_area(str vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
@@ -113,7 +113,7 @@ arch_get_unmapped_area_topdown(struct fi vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
arch/sparc/kernel/sys_sparc_64.c +2 -2
@@ -118,7 +118,7 @@ unsigned long arch_get_unmapped_area(str vma =find_vma (mm, addr);if (task_size - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
@@ -181,7 +181,7 @@ arch_get_unmapped_area_topdown(struct fi vma =find_vma (mm, addr);if (task_size - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
arch/sparc/mm/hugetlbpage.c +1 -1
@@ -115,7 +115,7 @@ hugetlb_get_unmapped_area(struct file *f addr =ALIGN (addr,HPAGE_SIZE ); vma =find_vma (mm, addr);if (task_size - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }if (mm->get_unmapped_area == arch_get_unmapped_area)
arch/tile/mm/hugetlbpage.c +1 -1
@@ -232,7 +232,7 @@ unsigned long hugetlb_get_unmapped_area( addr =ALIGN (addr,huge_page_size (h)); vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }if (current->mm->get_unmapped_area == arch_get_unmapped_area)
arch/x86/kernel/sys_x86_64.c +2 -2
@@ -143,7 +143,7 @@ arch_get_unmapped_area(struct file *filp addr =PAGE_ALIGN (addr); vma =find_vma (mm, addr);if (end - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
@@ -186,7 +186,7 @@ arch_get_unmapped_area_topdown(struct fi addr =PAGE_ALIGN (addr); vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
arch/x86/mm/hugetlbpage.c +1 -1
@@ -144,7 +144,7 @@ hugetlb_get_unmapped_area(struct file *f addr =ALIGN (addr,huge_page_size (h)); vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }if (mm->get_unmapped_area == arch_get_unmapped_area)
arch/xtensa/kernel/syscall.c +1 -1
@@ -87,7 +87,7 @@ unsigned long arch_get_unmapped_area(str/* At this point: (!vmm || addr < vmm->vm_end). */ if (TASK_SIZE - len < addr)return -ENOMEM ; -if (!vmm || addr + len <= vmm->vm_start) +if (!vmm || addr + len <=vm_start_gap (vmm))return addr; addr = vmm->vm_end;if (flags &MAP_SHARED )
fs/hugetlbfs/inode.c +1 -1
@@ -191,7 +191,7 @@ hugetlb_get_unmapped_area(struct file *f addr =ALIGN (addr,huge_page_size (h)); vma =find_vma (mm, addr);if (TASK_SIZE - len >= addr && - (!vma || addr + len <= vma->vm_start)) + (!vma || addr + len <=vm_start_gap (vma)))return addr; }
fs/proc/task_mmu.c +0 -4
@@ -295,11 +295,7 @@ show_map_vma(struct seq_file *m, struct/* We don't show the stack guard page in /proc/maps */ start = vma->vm_start; -if (stack_guard_page_start (vma, start)) - start +=PAGE_SIZE ; end = vma->vm_end; -if (stack_guard_page_end (vma, end)) - end -=PAGE_SIZE ;seq_setwidth (m,25 +sizeof (void *) *6 -1 ); seq_printf(m, "%08lx-%08lx %c%c%c%c %08llx %02x:%02x %lu ",
include/linux/mm.h +25 -30
78 lines not on this page · raw message
mm/gup.c +0 -5
@@ -312,11 +312,6 @@ static int faultin_page(struct task_stru/* mlock all present pages, but do not fault in new pages */ if ((*flags & (FOLL_POPULATE |FOLL_MLOCK )) ==FOLL_MLOCK )return -ENOENT ; -/* For mm_populate(), just skip the stack guard page. */ -if ((*flags &FOLL_POPULATE ) && - (stack_guard_page_start (vma, address) || -stack_guard_page_end (vma, address +PAGE_SIZE ))) -return -ENOENT ;if (*flags &FOLL_WRITE ) fault_flags |=FAULT_FLAG_WRITE ;if (nonblocking)
mm/memory.c +0 -38
@@ -2662,40 +2662,6 @@ out_release: }/* -* This is like a special single-page "expand_{down|up}wards()", -* except we must first make sure that 'address{-|+}PAGE_SIZE' -* doesn't hit another vma. -*/ -static inline int check_stack_guard_page (struct vm_area_struct *vma,unsigned long address) -{ - address &=PAGE_MASK ; -if ((vma->vm_flags &VM_GROWSDOWN ) && address == vma->vm_start) { -struct vm_area_struct *prev = vma->vm_prev; - -/* -* Is there a mapping abutting this one below? -* -* That's only ok if it's the same stack mapping -* that has gotten split.. -*/ -if (prev && prev->vm_end == address) -return prev->vm_flags &VM_GROWSDOWN ?0 : -ENOMEM ; - -return expand_downwards (vma, address -PAGE_SIZE ); - } -if ((vma->vm_flags &VM_GROWSUP ) && address +PAGE_SIZE == vma->vm_end) { -struct vm_area_struct *next = vma->vm_next; - -/* As VM_GROWSDOWN but s/below/above/ */ -if (next && next->vm_start == address +PAGE_SIZE ) -return next->vm_flags &VM_GROWSUP ?0 : -ENOMEM ; - -return expand_upwards (vma, address +PAGE_SIZE ); - } -return 0 ; -} - -/* * We enter with non-exclusive mmap_sem (to exclude vma changes, * but allow concurrent faults), and pte mapped but not yet locked. * We return with mmap_sem still held, but pte unmapped and unlocked.
@@ -2715,10 +2681,6 @@ static int do_anonymous_page(struct mm_sif (vma->vm_flags &VM_SHARED )return VM_FAULT_SIGBUS ; -/* Check if we need to add a guard page to the stack */ -if (check_stack_guard_page (vma, address) <0 ) -return VM_FAULT_SIGSEGV ; -/* Use the zero-page for reads */ if (!(flags &FAULT_FLAG_WRITE ) && !mm_forbids_zeropage (mm)) { entry = pte_mkspecial(pfn_pte(my_zero_pfn(address),
mm/mmap.c +88 -59
313 lines not on this page · raw message
Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas
Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugh Dickins <[email protected]>
commit
1be7107fbe18eed3e319a6c3e83c78254b693acbupstream.
The 4.11 and 4.9 patches are fine, but I noticed a couple of corrections to this 4.4 one. There are very unlikely circumstances (on VM_GROWSUP architectures only) in which that "highest_vm_end = end" line would be
wrong: several different ways to fix it, I'm tending to go with Andrea's observation that the only need for update has already been done above, so just VM_WARN_ON if it's unexpected.
Hugh
include/linux/mm.h +2 -0
@@ -1283,6 +1283,8 @@ static inline bool vma_is_anonymous(strureturn !vma->vm_ops; } +int vma_is_stack_for_task (struct vm_area_struct *vma,struct task_struct *t); + extern unsigned long move_page_tables(struct vm_area_struct *vma, unsigned long old_addr, struct vm_area_struct *new_vma, unsigned long new_addr, unsigned long len,
mm/mmap.c +1 -1
@@ -923,7 +923,7 @@ again: remove_next = 1 + (end > next->else if (next)vma_gap_update (next);else - mm->highest_vm_end = end; +VM_WARN_ON (mm->highest_vm_end !=vm_end_gap (vma)); }if (insert && file)uprobe_mmap (insert);
Greg Kroah-Hartman
maintainerRe: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas
Quoted 35 lines · Hugh Dickins
Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugh Dickins <[email protected]>
commit
1be7107fbe18eed3e319a6c3e83c78254b693acbupstream.The 4.11 and 4.9 patches are fine, but I noticed a couple of corrections to this 4.4 one. There are very unlikely circumstances (on
VM_GROWSUParchitectures only) in which that "highest_vm_end= end" line would be
wrong: several different ways to fix it, I'm tending to go with Andrea's observation that the only need for update has already been done above, so justVM_WARN_ONif it's unexpected.Hugh
diff -purN
404n/include/linux/mm.h404h/include/linux/mm.hinclude/linux/mm.h +2
-0@@ -1283,6 +1283,8 @@ static inline bool vma_is_anonymous(strureturn !vma->vm_ops; } +int vma_is_stack_for_task (struct vm_area_struct *vma,struct task_struct *t); + extern unsigned long move_page_tables(struct vm_area_struct *vma, unsigned long old_addr, struct vm_area_struct *new_vma, unsigned long new_addr, unsigned long len,diff -purN
404n/mm/mmap.c404h/mm/mmap.c
mm/mmap.c again: remove_next = 1 + (end > next-> · line 929
Quoted 8 lines
mm/mmap.c +1
-1@@ -923,7 +923,7 @@ again: remove_next = 1 + (end > next->else if (next)vma_gap_update (next);else - mm->highest_vm_end = end; +VM_WARN_ON (mm->highest_vm_end !=vm_end_gap (vma)); }if (insert && file)uprobe_mmap (insert);
Thank you, the first chunk was already in my updated tree, and I have now added the second chunk and will run it through the 0-day tests to see how it goes...
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.4.74 release. There are 30 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Jun 21 15:20:21 UTC 2017. Anything received after that time might be too late.
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 115 pass: 115 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter