- Linux-stable-mirror - lists.linaro.org

[PATCH] MIPS/tlbex: Fix LDDIR usage in setup_pw() for Loongson-3

by Huacai Chen

LDDIR/LDPTE is Loongson-3's acceleration for Page Table Walking. If BD (Base Directory, the 4th page directory) is not enabled, then GDOffset is biased by BadVAddr[63:62]. So, if GDOffset (aka. BadVAddr[47:36] for Loongson-3) is big enough, "0b11(BadVAddr[63:62])|BadVAddr[47:36]|...." can far beyond pg_swapper_dir. This means the pg_swapper_dir may NOT be accessed by LDDIR correctly, so fix it by set PWDirExt in CP0_PWCtl. Cc: <stable(a)vger.kernel.org> Signed-off-by: Pei Huang <huangpei(a)loongson.cn> Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/mips/mm/tlbex.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c index 344e6e9..da407cd 100644 --- a/arch/mips/mm/tlbex.c +++ b/arch/mips/mm/tlbex.c @@ -1480,6 +1480,7 @@ static void build_r4000_tlb_refill_handler(void) static void setup_pw(void) { + unsigned int pwctl; unsigned long pgd_i, pgd_w; #ifndef __PAGETABLE_PMD_FOLDED unsigned long pmd_i, pmd_w; @@ -1506,6 +1507,7 @@ static void setup_pw(void) pte_i = ilog2(_PAGE_GLOBAL); pte_w = 0; + pwctl = 1 << 30; /* Set PWDirExt */ #ifndef __PAGETABLE_PMD_FOLDED write_c0_pwfield(pgd_i << 24 | pmd_i << 12 | pt_i << 6 | pte_i); @@ -1516,8 +1518,9 @@ static void setup_pw(void) #endif #ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT - write_c0_pwctl(1 << 6 | psn); + pwctl |= (1 << 6 | psn); #endif + write_c0_pwctl(pwctl); write_c0_kpgd((long)swapper_pg_dir); kscratch_used_mask |= (1 << 7); /* KScratch6 is used for KPGD */ } -- 2.7.0

5 years, 8 months

3
3
0 0

[PATCH v3] mm/hugetlb: fix a addressing exception caused by huge_pte_offset

by Longpeng(Mike)

From: Longpeng <longpeng2(a)huawei.com> Our machine encountered a panic(addressing exception) after run for a long time and the calltrace is: RIP: 0010:[<ffffffff9dff0587>] [<ffffffff9dff0587>] hugetlb_fault+0x307/0xbe0 RSP: 0018:ffff9567fc27f808 EFLAGS: 00010286 RAX: e800c03ff1258d48 RBX: ffffd3bb003b69c0 RCX: e800c03ff1258d48 RDX: 17ff3fc00eda72b7 RSI: 00003ffffffff000 RDI: e800c03ff1258d48 RBP: ffff9567fc27f8c8 R08: e800c03ff1258d48 R09: 0000000000000080 R10: ffffaba0704c22a8 R11: 0000000000000001 R12: ffff95c87b4b60d8 R13: 00005fff00000000 R14: 0000000000000000 R15: ffff9567face8074 FS: 00007fe2d9ffb700(0000) GS:ffff956900e40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffd3bb003b69c0 CR3: 000000be67374000 CR4: 00000000003627e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff9df9b71b>] ? unlock_page+0x2b/0x30 [<ffffffff9dff04a2>] ? hugetlb_fault+0x222/0xbe0 [<ffffffff9dff1405>] follow_hugetlb_page+0x175/0x540 [<ffffffff9e15b825>] ? cpumask_next_and+0x35/0x50 [<ffffffff9dfc7230>] __get_user_pages+0x2a0/0x7e0 [<ffffffff9dfc648d>] __get_user_pages_unlocked+0x15d/0x210 [<ffffffffc068cfc5>] __gfn_to_pfn_memslot+0x3c5/0x460 [kvm] [<ffffffffc06b28be>] try_async_pf+0x6e/0x2a0 [kvm] [<ffffffffc06b4b41>] tdp_page_fault+0x151/0x2d0 [kvm] ... [<ffffffffc06a6f90>] kvm_arch_vcpu_ioctl_run+0x330/0x490 [kvm] [<ffffffffc068d919>] kvm_vcpu_ioctl+0x309/0x6d0 [kvm] [<ffffffff9deaa8c2>] ? dequeue_signal+0x32/0x180 [<ffffffff9deae34d>] ? do_sigtimedwait+0xcd/0x230 [<ffffffff9e03aed0>] do_vfs_ioctl+0x3f0/0x540 [<ffffffff9e03b0c1>] SyS_ioctl+0xa1/0xc0 [<ffffffff9e53879b>] system_call_fastpath+0x22/0x27 For 1G hugepages, huge_pte_offset() wants to return NULL or pudp, but it may return a wrong 'pmdp' if there is a race. Please look at the following code snippet: ... pud = pud_offset(p4d, addr); if (sz != PUD_SIZE && pud_none(*pud)) return NULL; /* hugepage or swap? */ if (pud_huge(*pud) || !pud_present(*pud)) return (pte_t *)pud; pmd = pmd_offset(pud, addr); if (sz != PMD_SIZE && pmd_none(*pmd)) return NULL; /* hugepage or swap? */ if (pmd_huge(*pmd) || !pmd_present(*pmd)) return (pte_t *)pmd; ... The following sequence would trigger this bug: 1. CPU0: sz = PUD_SIZE and *pud = 0 , continue 1. CPU0: "pud_huge(*pud)" is false 2. CPU1: calling hugetlb_no_page and set *pud to xxxx8e7(PRESENT) 3. CPU0: "!pud_present(*pud)" is false, continue 4. CPU0: pmd = pmd_offset(pud, addr) and maybe return a wrong pmdp However, we want CPU0 to return NULL or pudp in this case. Also, according to the section 'COMPILER BARRIER' of memory-barriers.txt: ''' (*) The compiler is within its rights to reorder loads and stores to the same variable, and in some cases, the CPU is within its rights to reorder loads to the same variable. This means that the following code: a[0] = x; a[1] = x; Might result in an older value of x stored in a[1] than in a[0]. ''' there're several other data races in huge_pte_offset, for example: ''' p4d = p4d_offset(pgd, addr) if (!p4d_present(*p4d)) return NULL; pud = pud_offset(p4d, addr) <-- will be unwinded as: pud = (pud_t *)p4d_page_vaddr(*p4d) + pud_index(address); ''' which is free for the compiler/CPU to execute as: ''' p4d = p4d_offset(pgd, addr) p4d_for_vaddr = *p4d; if (!p4d_present(*p4d)) return NULL; pud = (pud_t *)p4d_page_vaddr(p4d_for_vaddr) + pud_index(address); ''' so in the case where *p4g goes from '!present' to 'present': p4d_present(*p4d) and p4d_for_vaddr == none, meaning the p4d_page_vaddr() will crash. For these reasons, we must make sure there is exactly one dereference of p4g, pud and pmd. Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Sean Christopherson <sean.j.christopherson(a)intel.com> Cc: stable(a)vger.kernel.org Suggested-by: Jason Gunthorpe <jgg(a)ziepe.ca> Signed-off-by: Longpeng <longpeng2(a)huawei.com> --- v2 -> v3: make sure p4g/pud/pmd be dereferenced once. [Jason] --- mm/hugetlb.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index dd8737a..d4fab68 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4909,29 +4909,33 @@ pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr, unsigned long sz) { pgd_t *pgd; - p4d_t *p4d; - pud_t *pud; - pmd_t *pmd; + p4d_t *p4g, p4d_entry; + pud_t *pud, pud_entry; + pmd_t *pmd, pmd_entry; pgd = pgd_offset(mm, addr); if (!pgd_present(*pgd)) return NULL; - p4d = p4d_offset(pgd, addr); - if (!p4d_present(*p4d)) + + p4g = p4d_offset(pgd, addr); + p4d_entry = READ_ONCE(*p4g); + if (!p4d_present(p4d_entry)) return NULL; - pud = pud_offset(p4d, addr); - if (sz != PUD_SIZE && pud_none(*pud)) + pud = pud_offset(&p4d_entry, addr); + pud_entry = READ_ONCE(*pud); + if (sz != PUD_SIZE && pud_none(pud_entry)) return NULL; /* hugepage or swap? */ - if (pud_huge(*pud) || !pud_present(*pud)) + if (pud_huge(pud_entry) || !pud_present(pud_entry)) return (pte_t *)pud; - pmd = pmd_offset(pud, addr); - if (sz != PMD_SIZE && pmd_none(*pmd)) + pmd = pmd_offset(&pud_entry, addr); + pmd_entry = READ_ONCE(*pmd); + if (sz != PMD_SIZE && pmd_none(pmd_entry)) return NULL; /* hugepage or swap? */ - if (pmd_huge(*pmd) || !pmd_present(*pmd)) + if (pmd_huge(pmd_entry) || !pmd_present(pmd_entry)) return (pte_t *)pmd; return NULL; -- 1.8.3.1

5 years, 8 months

4
3
0 0

[PATCH v2 2/3] platform/x86: intel-hid: fix: Update Tiger Lake ACPI device ID

by Gayatri Kammela

Tiger Lake's new unique ACPI device IDs for intel-hid driver is not valid because of missing 'C' in the ID. Fix the ID by updating it. After the update, the new ID should now look like INT1051 --> INTC1051 Fixes: bdd11b654035 ("platform/x86: intel-hid: Add Tiger Lake ACPI device ID") Cc: 5.6+ <stable(a)vger.kernel.org> # 5.6+ Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada(a)intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Suggested-by: Srinivas Pandruvada <srinivas.pandruvada(a)intel.com> Signed-off-by: Gayatri Kammela <gayatri.kammela(a)intel.com> --- drivers/platform/x86/intel-hid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/intel-hid.c b/drivers/platform/x86/intel-hid.c index 43d590250228..c0a4696803eb 100644 --- a/drivers/platform/x86/intel-hid.c +++ b/drivers/platform/x86/intel-hid.c @@ -19,7 +19,7 @@ MODULE_LICENSE("GPL"); MODULE_AUTHOR("Alex Hung"); static const struct acpi_device_id intel_hid_ids[] = { - {"INT1051", 0}, + {"INTC1051", 0}, {"INT33D5", 0}, {"", 0}, }; -- 2.17.1

5 years, 8 months

1
0
0 0

[PATCH] tools: gpio: Fix out-of-tree build regression

by Anssi Hannula

Commit 0161a94e2d1c7 ("tools: gpio: Correctly add make dependencies for gpio_utils") added a make rule for gpio-utils-in.o but used $(output) instead of the correct $(OUTPUT) for the output directory, breaking out-of-tree build (O=xx) with the following error: No rule to make target 'out/tools/gpio/gpio-utils-in.o', needed by 'out/tools/gpio/lsgpio-in.o'. Stop. Fix that. Fixes: 0161a94e2d1c ("tools: gpio: Correctly add make dependencies for gpio_utils") Cc: <stable(a)vger.kernel.org> Cc: Laura Abbott <labbott(a)redhat.com> Signed-off-by: Anssi Hannula <anssi.hannula(a)bitwise.fi> --- The 0161a94e2d1c was also applied to stable releases, which is where I got hit by the issue. tools/gpio/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/gpio/Makefile b/tools/gpio/Makefile index 842287e42c83..440434027557 100644 --- a/tools/gpio/Makefile +++ b/tools/gpio/Makefile @@ -35,7 +35,7 @@ $(OUTPUT)include/linux/gpio.h: ../../include/uapi/linux/gpio.h prepare: $(OUTPUT)include/linux/gpio.h -GPIO_UTILS_IN := $(output)gpio-utils-in.o +GPIO_UTILS_IN := $(OUTPUT)gpio-utils-in.o $(GPIO_UTILS_IN): prepare FORCE $(Q)$(MAKE) $(build)=gpio-utils -- 2.21.1

5 years, 8 months

3
2
0 0

[PATCH 01/11] rtc: max8907: add missing select REGMAP_IRQ

by Jules Irenge

From: Corentin Labbe <clabbe(a)baylibre.com> I have hit the following build error: armv7a-hardfloat-linux-gnueabi-ld: drivers/rtc/rtc-max8907.o: in function `max8907_rtc_probe': rtc-max8907.c:(.text+0x400): undefined reference to `regmap_irq_get_virq' max8907 should select REGMAP_IRQ Fixes: 94c01ab6d7544 ("rtc: add MAX8907 RTC driver") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Corentin Labbe <clabbe(a)baylibre.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- drivers/rtc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 34c8b6c7e095..8e503881d9d6 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -327,6 +327,7 @@ config RTC_DRV_MAX6900 config RTC_DRV_MAX8907 tristate "Maxim MAX8907" depends on MFD_MAX8907 || COMPILE_TEST + select REGMAP_IRQ help If you say yes here you will get support for the RTC of Maxim MAX8907 PMIC. -- 2.25.1

5 years, 8 months

1
1
0 0

patch "USB: cdc-acm: restore capability check order" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: cdc-acm: restore capability check order to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From 62d65bdd9d05158aa2547f8ef72375535f3bc6e3 Mon Sep 17 00:00:00 2001 From: Matthias Reichl <hias(a)horus.com> Date: Fri, 27 Mar 2020 16:03:50 +0100 Subject: USB: cdc-acm: restore capability check order commit b401f8c4f492c ("USB: cdc-acm: fix rounding error in TIOCSSERIAL") introduced a regression by changing the order of capability and close settings change checks. When running with CAP_SYS_ADMIN setting the close settings to the values already set resulted in -EOPNOTSUPP. Fix this by changing the check order back to how it was before. Fixes: b401f8c4f492c ("USB: cdc-acm: fix rounding error in TIOCSSERIAL") Cc: Anthony Mallet <anthony.mallet(a)laas.fr> Cc: stable <stable(a)vger.kernel.org> Cc: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: Matthias Reichl <hias(a)horus.com> Link: https://lore.kernel.org/r/20200327150350.3657-1-hias@horus.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-acm.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index 47f09a6ce7bd..84d6f7df09a4 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -923,16 +923,16 @@ static int set_serial_info(struct tty_struct *tty, struct serial_struct *ss) mutex_lock(&acm->port.mutex); - if ((ss->close_delay != old_close_delay) || - (ss->closing_wait != old_closing_wait)) { - if (!capable(CAP_SYS_ADMIN)) + if (!capable(CAP_SYS_ADMIN)) { + if ((ss->close_delay != old_close_delay) || + (ss->closing_wait != old_closing_wait)) retval = -EPERM; - else { - acm->port.close_delay = close_delay; - acm->port.closing_wait = closing_wait; - } - } else - retval = -EOPNOTSUPP; + else + retval = -EOPNOTSUPP; + } else { + acm->port.close_delay = close_delay; + acm->port.closing_wait = closing_wait; + } mutex_unlock(&acm->port.mutex); return retval; -- 2.26.0

5 years, 8 months

1
0
0 0

[PATCH 1/2] mac80211: Check port authorization in the ieee80211_tx_dequeue() case

by Johannes Berg

From: Jouni Malinen <jouni(a)codeaurora.org> mac80211 used to check port authorization in the Data frame enqueue case when going through start_xmit(). However, that authorization status may change while the frame is waiting in a queue. Add a similar check in the dequeue case to avoid sending previously accepted frames after authorization change. This provides additional protection against potential leaking of frames after a station has been disconnected and the keys for it are being removed. Cc: stable(a)vger.kernel.org Signed-off-by: Jouni Malinen <jouni(a)codeaurora.org> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> --- net/mac80211/tx.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 7dbfb9e3cd84..455eb8e6a459 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -3604,8 +3604,25 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw, tx.skb = skb; tx.sdata = vif_to_sdata(info->control.vif); - if (txq->sta) + if (txq->sta) { tx.sta = container_of(txq->sta, struct sta_info, sta); + /* + * Drop unicast frames to unauthorised stations unless they are + * EAPOL frames from the local station. + */ + if (unlikely(!ieee80211_vif_is_mesh(&tx.sdata->vif) && + tx.sdata->vif.type != NL80211_IFTYPE_OCB && + !is_multicast_ether_addr(hdr->addr1) && + !test_sta_flag(tx.sta, WLAN_STA_AUTHORIZED) && + (!(info->control.flags & + IEEE80211_TX_CTRL_PORT_CTRL_PROTO) || + !ether_addr_equal(tx.sdata->vif.addr, + hdr->addr2)))) { + I802_DEBUG_INC(local->tx_handlers_drop_unauth_port); + ieee80211_free_txskb(&local->hw, skb); + goto begin; + } + } /* * The key can be removed while the packet was queued, so need to call -- 2.25.1

5 years, 8 months

3
5
0 0

[PATCH] kernel/taskstats: fix wrong nla type for {cgroup, task}stats policy

by Yafang Shao

After our server is upgraded to a newer kernel, we found that it continuesly print a warning in the kernel message. The warning is, [832984.946322] netlink: 'irmas.lc': attribute type 1 has an invalid length. irmas.lc is one of our container monitor daemons, and it will use CGROUPSTATS_CMD_GET to get the cgroupstats, that is similar with tools/accounting/getdelays.c. We can also produce this warning with getdelays. For example, after running bellow command $ ./getdelays -C /sys/fs/cgroup/memory then you can find a warning in dmesg, [61607.229318] netlink: 'getdelays': attribute type 1 has an invalid length. This warning is introduced in commit 6e237d099fac ("netlink: Relax attr validation for fixed length types"), which is used to check whether attributes using types NLA_U* and NLA_S* have an exact length. Regarding this issue, the root cause is cgroupstats_cmd_get_policy defines a wrong type as NLA_U32, while it should be NLA_NESTED an its minimal length is NLA_HDRLEN. That is similar to taskstats_cmd_get_policy. As this behavior change really breaks our application, we'd better cc stable as well. Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com> Cc: stable(a)vger.kernel.org --- kernel/taskstats.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/taskstats.c b/kernel/taskstats.c index e2ac0e3..b90a520 100644 --- a/kernel/taskstats.c +++ b/kernel/taskstats.c @@ -35,8 +35,8 @@ static struct genl_family family; static const struct nla_policy taskstats_cmd_get_policy[TASKSTATS_CMD_ATTR_MAX+1] = { - [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_U32 }, - [TASKSTATS_CMD_ATTR_TGID] = { .type = NLA_U32 }, + [TASKSTATS_CMD_ATTR_PID] = { .type = NLA_NESTED }, + [TASKSTATS_CMD_ATTR_TGID] = { .type = NLA_NESTED }, [TASKSTATS_CMD_ATTR_REGISTER_CPUMASK] = { .type = NLA_STRING }, [TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK] = { .type = NLA_STRING },}; @@ -45,7 +45,7 @@ * Make sure they are always aligned. */ static const struct nla_policy cgroupstats_cmd_get_policy[TASKSTATS_CMD_ATTR_MAX+1] = { - [CGROUPSTATS_CMD_ATTR_FD] = { .type = NLA_U32 }, + [CGROUPSTATS_CMD_ATTR_FD] = { .type = NLA_NESTED }, }; struct listener { -- 1.8.3.1

5 years, 8 months

2
1
0 0

Re: [PATCH 11/12] mac80211: drop data frames without key on encrypted links

by Sasha Levin

Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.5.11, v5.4.27, v4.19.112, v4.14.174, v4.9.217, v4.4.217. v5.5.11: Build OK! v5.4.27: Build OK! v4.19.112: Failed to apply! Possible dependencies: 03512ceb60ae ("ieee80211: remove redundant leading zeroes") 09b4a4faf9d0 ("mac80211: introduce capability flags for VHT EXT NSS support") 0eeb2b674f05 ("mac80211: add an option for station management TXQ") 1c9559734eca ("mac80211: remove unnecessary key condition") 57a3a454f303 ("iwlwifi: split HE capabilities between AP and STA") 62872a9b9a10 ("mac80211: Fix PTK rekey freezes and clear text leak") 77f7ffdc335d ("mac80211: minstrel_ht: add flag to indicate missing/inaccurate tx A-MPDU length") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 80aaa9c16415 ("mac80211: Add he_capa debugfs entry") 96fc6efb9ad9 ("mac80211: IEEE 802.11 Extended Key ID support") add7453ad62f ("wireless: align to draft 11ax D3.0") adf8ed01e4fd ("mac80211: add an optional TXQ for other PS-buffered frames") caf56338c22f ("mac80211: indicate support for multiple BSSID") daa5b83513a7 ("mac80211: update HE operation fields to D3.0") v4.14.174: Failed to apply! Possible dependencies: 110b32f065f3 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") 1c73acf58bd6 ("iwlwifi: acpi: move ACPI method definitions to acpi.h") 28e9c00fe1f0 ("iwlwifi: remove upper case letters in sku_capa_band_*_enable") 4ae80f6c8d86 ("iwlwifi: support api ver2 of NVM_GET_INFO resp") 4b82455ca51e ("iwlwifi: use flags to denote modifiers for the channel maps") 4c625c564ba2 ("iwlwifi: get rid of fw/nvm.c") 514c30696fbc ("iwlwifi: add support for IEEE802.11ax") 57a3a454f303 ("iwlwifi: split HE capabilities between AP and STA") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 813df5cef3bb ("iwlwifi: acpi: add common code to read from ACPI") 8a6171a7b601 ("iwlwifi: fw: add FW APIs for HE") 9c4f7d512740 ("iwlwifi: move all NVM parsing code to the common files") 9f66a397c877 ("iwlwifi: mvm: rs: add ops for the new rate scaling in the FW") e7a3b8d87910 ("iwlwifi: acpi: move ACPI-related definitions to acpi.h") v4.9.217: Failed to apply! Possible dependencies: 01796ff2fa6e ("iwlwifi: mvm: always free inactive queue when moving ownership") 0aaece81114e ("iwlwifi: split firmware API from iwl-trans.h") 1ea423b0e047 ("iwlwifi: remove unnecessary dev_cmd_headroom parameter") 310181ec34e2 ("iwlwifi: move to TVQM mode") 5594d80e9bf4 ("iwlwifi: support two phys for a000 devices") 623e7766be90 ("iwlwifi: pcie: introduce split point to a000 devices") 65e254821cee ("iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS") 6b35ff91572f ("iwlwifi: pcie: introduce a000 TX queues management") 727c02dfb848 ("iwlwifi: pcie: cleanup rfkill checks") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 8236f7db2724 ("iwlwifi: mvm: assign cab queue to the correct station") 87d0e1af9db3 ("iwlwifi: mvm: separate queue mapping from queue enablement") bb49701b41de ("iwlwifi: mvm: support a000 SCD queue configuration") cf90da352a32 ("iwlwifi: mvm: use mvm_disable_queue instead of sharing logic") d172a5eff629 ("iwlwifi: reorganize firmware API") df88c08d5c7e ("iwlwifi: mvm: release static queues on bcast release") eda50cde58de ("iwlwifi: pcie: add context information support") v4.4.217: Failed to apply! Possible dependencies: 0aaece81114e ("iwlwifi: split firmware API from iwl-trans.h") 13555e8ba2f4 ("iwlwifi: mvm: add 9000-series RX API") 1a616dd2f171 ("iwlwifi: dump prph registers in a common place for all transports") 1e0bbebaae66 ("mac80211: enable starting BA session with custom timeout") 2f89a5d7d377 ("iwlwifi: mvm: move fw-dbg code to separate file") 39bdb17ebb5b ("iwlwifi: update host command messages to new format") 41837ca962ec ("iwlwifi: pcie: allow to pretend to have Tx CSUM for debug") 4707fde5cdef ("iwlwifi: mvm: use build-time assertion for fw trigger ID") 5b88792cd850 ("iwlwifi: move to wide ID for all commands") 6c4fbcbc1c95 ("iwlwifi: add support for 12K Receive Buffers") 77ff2c6b4984 ("mac80211: update HE IEs to D3.3") 92fe83430b89 ("iwlwifi: uninline iwl_trans_send_cmd") d172a5eff629 ("iwlwifi: reorganize firmware API") dcbb4746286a ("iwlwifi: trans: support a callback for ASYNC commands") NOTE: The patch will not be queued to stable trees until it is upstream. How should we proceed with this patch? -- Thanks Sasha

5 years, 8 months

1
0
0 0

[PATCH v2] usb: gadget: f_fs: Fix use after free issue as part of queue failure

by Sriharsha Allenki

In AIO case, the request is freed up if ep_queue fails. However, io_data->req still has the reference to this freed request. In the case of this failure if there is aio_cancel call on this io_data it will lead to an invalid dequeue operation and a potential use after free issue. Fix this by setting the io_data->req to NULL when the request is freed as part of queue failure. Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support") Signed-off-by: Sriharsha Allenki <sallenki(a)codeaurora.org> CC: stable <stable(a)vger.kernel.org> Reviewed-by: Peter Chen <peter.chen(a)nxp.com> --- Changes in v2: - As suggested by Greg, updated the tags drivers/usb/gadget/function/f_fs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 571917677d35..767f30b86645 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -1120,6 +1120,7 @@ static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data) ret = usb_ep_queue(ep->ep, req, GFP_ATOMIC); if (unlikely(ret)) { + io_data->req = NULL; usb_ep_free_request(ep->ep, req); goto error_lock; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

5 years, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror