February 2021 - Linux-stable-mirror

[merged] net-fix-iteration-for-sctp-transport-seq_files.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: net: fix iteration for sctp transport seq_files has been removed from the -mm tree. Its filename was net-fix-iteration-for-sctp-transport-seq_files.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: NeilBrown <neilb(a)suse.de> Subject: net: fix iteration for sctp transport seq_files The sctp transport seq_file iterators take a reference to the transport in the ->start and ->next functions and releases the reference in the ->show function. The preferred handling for such resources is to release them in the subsequent ->next or ->stop function call. Since Commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") there is no guarantee that ->show will be called after ->next, so this function can now leak references. So move the sctp_transport_put() call to ->next and ->stop. Link: https://lkml.kernel.org/r/161248539022.21478.17038123892954492263.stgit@nob… Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Signed-off-by: NeilBrown <neilb(a)suse.de> Reported-by: Xin Long <lucien.xin(a)gmail.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Vlad Yasevich <vyasevich(a)gmail.com> Cc: Neil Horman <nhorman(a)tuxdriver.com> Cc: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- net/sctp/proc.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) --- a/net/sctp/proc.c~net-fix-iteration-for-sctp-transport-seq_files +++ a/net/sctp/proc.c @@ -215,6 +215,12 @@ static void sctp_transport_seq_stop(stru { struct sctp_ht_iter *iter = seq->private; + if (v && v != SEQ_START_TOKEN) { + struct sctp_transport *transport = v; + + sctp_transport_put(transport); + } + sctp_transport_walk_stop(&iter->hti); } @@ -222,6 +228,12 @@ static void *sctp_transport_seq_next(str { struct sctp_ht_iter *iter = seq->private; + if (v && v != SEQ_START_TOKEN) { + struct sctp_transport *transport = v; + + sctp_transport_put(transport); + } + ++*pos; return sctp_transport_get_next(seq_file_net(seq), &iter->hti); @@ -277,8 +289,6 @@ static int sctp_assocs_seq_show(struct s sk->sk_rcvbuf); seq_printf(seq, "\n"); - sctp_transport_put(transport); - return 0; } @@ -354,8 +364,6 @@ static int sctp_remaddr_seq_show(struct seq_printf(seq, "\n"); } - sctp_transport_put(transport); - return 0; } _ Patches currently in -mm which might be from neilb(a)suse.de are seq_file-document-how-per-entry-resources-are-managed.patch x86-fix-seq_file-iteration-for-pat-memtypec.patch

3 years, 8 months

1
0
0 0

patch "usb: dwc3: gadget: Fix dep->interval for fullspeed interrupt" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: gadget: Fix dep->interval for fullspeed interrupt 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-next 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 also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 4b049f55ed95cd889bcdb3034fd75e1f01852b38 Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Mon, 8 Feb 2021 13:53:16 -0800 Subject: usb: dwc3: gadget: Fix dep->interval for fullspeed interrupt The dep->interval captures the number of frames/microframes per interval from bInterval. Fullspeed interrupt endpoint bInterval is the number of frames per interval and not 2^(bInterval - 1). So fix it here. This change is only for debugging purpose and should not affect the interrupt endpoint operation. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/1263b563dedc4ab8b0fb854fba06ce4bc56bd495.16128209… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/gadget.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d0f8d3ec855f..aebcf8ec0716 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -615,8 +615,13 @@ static int dwc3_gadget_set_ep_config(struct dwc3_ep *dep, unsigned int action) if (dwc->gadget->speed == USB_SPEED_FULL) bInterval_m1 = 0; + if (usb_endpoint_type(desc) == USB_ENDPOINT_XFER_INT && + dwc->gadget->speed == USB_SPEED_FULL) + dep->interval = desc->bInterval; + else + dep->interval = 1 << (desc->bInterval - 1); + params.param1 |= DWC3_DEPCFG_BINTERVAL_M1(bInterval_m1); - dep->interval = 1 << (desc->bInterval - 1); } return dwc3_send_gadget_ep_cmd(dep, DWC3_DEPCMD_SETEPCONFIG, &params); -- 2.30.0

3 years, 8 months

1
0
0 0

patch "usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1 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-next 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 also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From a1679af85b2ae35a2b78ad04c18bb069c37330cc Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Mon, 8 Feb 2021 13:53:10 -0800 Subject: usb: dwc3: gadget: Fix setting of DEPCFG.bInterval_m1 Valid range for DEPCFG.bInterval_m1 is from 0 to 13, and it must be set to 0 when the controller operates in full-speed. See the programming guide for DEPCFG command section 3.2.2.1 (v3.30a). Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/3f57026f993c0ce71498dbb06e49b3a47c4d0265.16128209… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/gadget.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 97d707b4f384..d0f8d3ec855f 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -605,7 +605,17 @@ static int dwc3_gadget_set_ep_config(struct dwc3_ep *dep, unsigned int action) params.param0 |= DWC3_DEPCFG_FIFO_NUMBER(dep->number >> 1); if (desc->bInterval) { - params.param1 |= DWC3_DEPCFG_BINTERVAL_M1(desc->bInterval - 1); + u8 bInterval_m1; + + /* + * Valid range for DEPCFG.bInterval_m1 is from 0 to 13, and it + * must be set to 0 when the controller operates in full-speed. + */ + bInterval_m1 = min_t(u8, desc->bInterval - 1, 13); + if (dwc->gadget->speed == USB_SPEED_FULL) + bInterval_m1 = 0; + + params.param1 |= DWC3_DEPCFG_BINTERVAL_M1(bInterval_m1); dep->interval = 1 << (desc->bInterval - 1); } -- 2.30.0

3 years, 8 months

1
0
0 0

patch "drivers/misc/vmw_vmci: restrict too big queue size in" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drivers/misc/vmw_vmci: restrict too big queue size in to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next 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 also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 2fd10bcf0310b9525b2af9e1f7aa9ddd87c3772e Mon Sep 17 00:00:00 2001 From: Sabyrzhan Tasbolatov <snovitoll(a)gmail.com> Date: Tue, 9 Feb 2021 16:26:12 +0600 Subject: drivers/misc/vmw_vmci: restrict too big queue size in qp_host_alloc_queue syzbot found WARNING in qp_broker_alloc[1] in qp_host_alloc_queue() when num_pages is 0x100001, giving queue_size + queue_page_size bigger than KMALLOC_MAX_SIZE for kzalloc(), resulting order >= MAX_ORDER condition. queue_size + queue_page_size=0x8000d8, where KMALLOC_MAX_SIZE=0x400000. [1] Call Trace: alloc_pages include/linux/gfp.h:547 [inline] kmalloc_order+0x40/0x130 mm/slab_common.c:837 kmalloc_order_trace+0x15/0x70 mm/slab_common.c:853 kmalloc_large include/linux/slab.h:481 [inline] __kmalloc+0x257/0x330 mm/slub.c:3959 kmalloc include/linux/slab.h:557 [inline] kzalloc include/linux/slab.h:682 [inline] qp_host_alloc_queue drivers/misc/vmw_vmci/vmci_queue_pair.c:540 [inline] qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1351 [inline] qp_broker_alloc+0x936/0x2740 drivers/misc/vmw_vmci/vmci_queue_pair.c:1739 Reported-by: syzbot+15ec7391f3d6a1a7cc7d(a)syzkaller.appspotmail.com Signed-off-by: Sabyrzhan Tasbolatov <snovitoll(a)gmail.com> Link: https://lore.kernel.org/r/20210209102612.2112247-1-snovitoll@gmail.com Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/vmw_vmci/vmci_queue_pair.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c b/drivers/misc/vmw_vmci/vmci_queue_pair.c index d787ddecee77..880c33ab9f47 100644 --- a/drivers/misc/vmw_vmci/vmci_queue_pair.c +++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c @@ -539,6 +539,9 @@ static struct vmci_queue *qp_host_alloc_queue(u64 size) queue_page_size = num_pages * sizeof(*queue->kernel_if->u.h.page); + if (queue_size + queue_page_size > KMALLOC_MAX_SIZE) + return NULL; + queue = kzalloc(queue_size + queue_page_size, GFP_KERNEL); if (queue) { queue->q_header = NULL; -- 2.30.0

3 years, 8 months

1
0
0 0

patch "mei: bus: block send with vtag on non-conformat FW" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mei: bus: block send with vtag on non-conformat FW to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next 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 also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From b398d53cd421454d64850f8b1f6d609ede9042d9 Mon Sep 17 00:00:00 2001 From: Alexander Usyskin <alexander.usyskin(a)intel.com> Date: Mon, 8 Feb 2021 17:06:48 +0200 Subject: mei: bus: block send with vtag on non-conformat FW Block data send with vtag if either transport layer or FW client are not supporting vtags. Cc: <stable(a)vger.kernel.org> # v5.10+ Signed-off-by: Alexander Usyskin <alexander.usyskin(a)intel.com> Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com> Link: https://lore.kernel.org/r/20210208150649.141358-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/mei/bus.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index 580074e32599..935acc6bbf3c 100644 --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -61,6 +61,13 @@ ssize_t __mei_cl_send(struct mei_cl *cl, u8 *buf, size_t length, u8 vtag, goto out; } + if (vtag) { + /* Check if vtag is supported by client */ + rets = mei_cl_vt_support_check(cl); + if (rets) + goto out; + } + if (length > mei_cl_mtu(cl)) { rets = -EFBIG; goto out; -- 2.30.0

3 years, 8 months

1
0
0 0

DMA direct mapping fix for 5.4 and earlier stable branches

by Sumit Garg

Hi Christoph, Greg, Currently we are observing an incorrect address translation corresponding to DMA direct mapping methods on 5.4 stable kernel while sharing dmabuf from one device to another where both devices have their own coherent DMA memory pools. I am able to root cause this issue which is caused by incorrect virt to phys translation for addresses belonging to vmalloc space using virt_to_page(). But while looking at the mainline kernel, this patch [1] changes address translation from virt->to->phys to dma->to->phys which fixes the issue observed on 5.4 stable kernel as well (minimal fix [2]). So I would like to seek your suggestion for backport to stable kernels (5.4 or earlier) as to whether we should backport the complete mainline commit [1] or we should just apply the minimal fix [2]? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [2] minimal fix required for 5.4 stable kernel: commit bb0b3ff6e54d78370b6b0c04426f0d9192f31795 Author: Sumit Garg <sumit.garg(a)linaro.org> Date: Wed Feb 3 13:08:37 2021 +0530 dma-mapping: Fix common get_sgtable and mmap methods Currently common get_sgtable and mmap methods can only handle normal kernel addresses leading to incorrect handling of vmalloc addresses which is common means for DMA coherent memory mapping. So instead of cpu_addr, directly decode the physical address from dma_addr and hence decode corresponding page and pfn values. In this way we can handle normal kernel addresses as well as vmalloc addresses. This fix is inspired from following mainline commit: 34dc0ea6bc96 ("dma-direct: provide mmap and get_sgtable method overrides") This fixes an issue observed during dmabuf sharing from one device to another where both devices have their own coherent DMA memory pools. Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c index 8682a53..034bbae 100644 --- a/kernel/dma/mapping.c +++ b/kernel/dma/mapping.c @@ -127,7 +127,7 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt, return -ENXIO; page = pfn_to_page(pfn); } else { - page = virt_to_page(cpu_addr); + page = pfn_to_page(PHYS_PFN(dma_to_phys(dev, dma_addr))); } ret = sg_alloc_table(sgt, 1, GFP_KERNEL); @@ -214,7 +214,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma, if (!pfn_valid(pfn)) return -ENXIO; } else { - pfn = page_to_pfn(virt_to_page(cpu_addr)); + pfn = PHYS_PFN(dma_to_phys(dev, dma_addr)); } return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,

3 years, 8 months

6
11
0 0

[tip: timers/urgent] hrtimer: Update softirq_expires_next correctly in hrtimer_force_reprogram()

by tip-bot2 for Mikael Beckius

The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 0fcc7c20d2e2a65fb5b80d42841084e8509d085d Gitweb: https://git.kernel.org/tip/0fcc7c20d2e2a65fb5b80d42841084e8509d085d Author: Mikael Beckius <mikael.beckius(a)windriver.com> AuthorDate: Thu, 28 Jan 2021 15:02:08 +01:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Tue, 09 Feb 2021 16:18:42 +01:00 hrtimer: Update softirq_expires_next correctly in hrtimer_force_reprogram() hrtimer_force_reprogram() invokes __hrtimer_get_next_event() to find the earliest expiry time of all hrtimer bases. __hrtimer_get_next_event() does not update cpu_base::[softirq_]_expires_next. That needs to be done at the callsites. hrtimer_force_reprogram() updates cpu_base::softirq_expires_next only when the first expiring timer is a softirq timer and the soft interrupt is not activated. That's wrong because cpu_base::softirq_expires_next is left stale when the first expiring timer of all bases is a timer which expires in hard interrupt context. That becomes a problem when clock_settime() sets CLOCK_REALTIME forward and the first soft expiring timer is in the CLOCK_REALTIME_SOFT base. Setting CLOCK_REALTIME forward moves the clock MONOTONIC based expiry time of that timer before the stale cpu_base::softirq_expires_next. cpu_base::softirq_expires_next is cached to make the check for raising the soft interrupt fast. In the above case the soft interrupt won't be raised until clock monotonic reaches the stale cpu_base::softirq_expires_next value. That's incorrect, but what's worse it that if the softirq timer becomes the first expiring timer of all clock bases after the hard expiry timer has been handled the reprogramming of the clockevent from hrtimer_interrupt() will result in an interrupt storm. That happens because the reprogramming does not use cpu_base::softirq_expires_next, it uses __hrtimer_get_next_event() which returns the actual expiry time. Once clock MONOTONIC reaches cpu_base::softirq_expires_next the soft interrupt is raised and the storm subsides. Change the logic in hrtimer_force_reprogram() to evaluate the soft and hard bases seperately, update softirq_expires_next and handle the case when a soft expiring timer is the first of all bases by comparing the expiry times and updating the required cpu base fields. [ tglx: Modified it to avoid the double evaluation ] Fixes:5da70160462e ("hrtimer: Implement support for softirq based hrtimers") Signed-off-by: Mikael Beckius <mikael.beckius(a)windriver.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20210128140208.30264-1-mikael.beckius@windriver.c… --- kernel/time/hrtimer.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 743c852..88a0145 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -626,24 +626,30 @@ static inline int hrtimer_hres_active(void) static void hrtimer_force_reprogram(struct hrtimer_cpu_base *cpu_base, int skip_equal) { - ktime_t expires_next; + ktime_t expires_next, soft = KTIME_MAX; /* - * Find the current next expiration time. + * If the soft interrupt has already been activated, ignore the + * soft bases. They will be handled in the already raised soft + * interrupt. */ - expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_ALL); - - if (cpu_base->next_timer && cpu_base->next_timer->is_soft) { + if (!cpu_base->softirq_activated) { + soft = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_SOFT); /* - * When the softirq is activated, hrtimer has to be - * programmed with the first hard hrtimer because soft - * timer interrupt could occur too late. + * Update the soft expiry time. clock_settime() might have + * affected it. */ - if (cpu_base->softirq_activated) - expires_next = __hrtimer_get_next_event(cpu_base, - HRTIMER_ACTIVE_HARD); - else - cpu_base->softirq_expires_next = expires_next; + cpu_base->softirq_expires_next = soft; + } + + expires_next = __hrtimer_get_next_event(cpu_base, HRTIMER_ACTIVE_HARD); + /* + * If a softirq timer is expiring first, update cpu_base->next_timer + * and program the hardware with the soft expiry time. + */ + if (expires_next > soft) { + cpu_base->next_timer = cpu_base->softirq_next_timer; + expires_next = soft; } if (skip_equal && expires_next == cpu_base->expires_next)

3 years, 8 months

1
0
0 0

[PATCH mips-fixes] MIPS: compressed: fix build with enabled UBSAN

by Alexander Lobakin

Commit 1e35918ad9d1 ("MIPS: Enable Undefined Behavior Sanitizer UBSAN") added a possibility to build the entire kernel with UBSAN instrumentation for MIPS, with the exception for VDSO. However, self-extracting head wasn't been added to exceptions, so this occurs: mips-alpine-linux-musl-ld: arch/mips/boot/compressed/decompress.o: in function `FSE_buildDTable_wksp': decompress.c:(.text.FSE_buildDTable_wksp+0x278): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-alpine-linux-musl-ld: decompress.c:(.text.FSE_buildDTable_wksp+0x2a8): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-alpine-linux-musl-ld: decompress.c:(.text.FSE_buildDTable_wksp+0x2c4): undefined reference to `__ubsan_handle_shift_out_of_bounds' mips-alpine-linux-musl-ld: arch/mips/boot/compressed/decompress.o: decompress.c:(.text.FSE_buildDTable_raw+0x9c): more undefined references to `__ubsan_handle_shift_out_of_bounds' follow Add UBSAN_SANITIZE := n to mips/boot/compressed/Makefile to exclude it from instrumentation scope and fix this issue. Fixes: 1e35918ad9d1 ("MIPS: Enable Undefined Behavior Sanitizer UBSAN") Cc: stable(a)vger.kernel.org # 5.0+ Signed-off-by: Alexander Lobakin <alobakin(a)pm.me> --- arch/mips/boot/compressed/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile index 47cd9dc7454a..f93f72bcba97 100644 --- a/arch/mips/boot/compressed/Makefile +++ b/arch/mips/boot/compressed/Makefile @@ -37,6 +37,7 @@ KBUILD_AFLAGS := $(KBUILD_AFLAGS) -D__ASSEMBLY__ \ # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in. KCOV_INSTRUMENT := n GCOV_PROFILE := n +UBSAN_SANITIZE := n # decompressor objects (linked with vmlinuz) vmlinuzobjs-y := $(obj)/head.o $(obj)/decompress.o $(obj)/string.o -- 2.30.0

3 years, 8 months

2
1
0 0

patch "drivers/misc/vmw_vmci: restrict too big queue size in" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drivers/misc/vmw_vmci: restrict too big queue size in to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-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 char-misc-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 2fd10bcf0310b9525b2af9e1f7aa9ddd87c3772e Mon Sep 17 00:00:00 2001 From: Sabyrzhan Tasbolatov <snovitoll(a)gmail.com> Date: Tue, 9 Feb 2021 16:26:12 +0600 Subject: drivers/misc/vmw_vmci: restrict too big queue size in qp_host_alloc_queue syzbot found WARNING in qp_broker_alloc[1] in qp_host_alloc_queue() when num_pages is 0x100001, giving queue_size + queue_page_size bigger than KMALLOC_MAX_SIZE for kzalloc(), resulting order >= MAX_ORDER condition. queue_size + queue_page_size=0x8000d8, where KMALLOC_MAX_SIZE=0x400000. [1] Call Trace: alloc_pages include/linux/gfp.h:547 [inline] kmalloc_order+0x40/0x130 mm/slab_common.c:837 kmalloc_order_trace+0x15/0x70 mm/slab_common.c:853 kmalloc_large include/linux/slab.h:481 [inline] __kmalloc+0x257/0x330 mm/slub.c:3959 kmalloc include/linux/slab.h:557 [inline] kzalloc include/linux/slab.h:682 [inline] qp_host_alloc_queue drivers/misc/vmw_vmci/vmci_queue_pair.c:540 [inline] qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1351 [inline] qp_broker_alloc+0x936/0x2740 drivers/misc/vmw_vmci/vmci_queue_pair.c:1739 Reported-by: syzbot+15ec7391f3d6a1a7cc7d(a)syzkaller.appspotmail.com Signed-off-by: Sabyrzhan Tasbolatov <snovitoll(a)gmail.com> Link: https://lore.kernel.org/r/20210209102612.2112247-1-snovitoll@gmail.com Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/misc/vmw_vmci/vmci_queue_pair.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c b/drivers/misc/vmw_vmci/vmci_queue_pair.c index d787ddecee77..880c33ab9f47 100644 --- a/drivers/misc/vmw_vmci/vmci_queue_pair.c +++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c @@ -539,6 +539,9 @@ static struct vmci_queue *qp_host_alloc_queue(u64 size) queue_page_size = num_pages * sizeof(*queue->kernel_if->u.h.page); + if (queue_size + queue_page_size > KMALLOC_MAX_SIZE) + return NULL; + queue = kzalloc(queue_size + queue_page_size, GFP_KERNEL); if (queue) { queue->q_header = NULL; -- 2.30.0

3 years, 8 months

1
0
0 0

[PATCHv2] firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0

by richard.gong＠linux.intel.com

From: Richard Gong <richard.gong(a)intel.com> Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which aligns with the firmware settings. Cc: <stable(a)vger.kernel.org> # 5.9+ Fixes: 36847f9e3e56 ("firmware: correct reconfig flag and timeout values") Signed-off-by: Richard Gong <richard.gong(a)intel.com> --- v2: add tag Cc: <stable(a)vger.kernel.org> # 5.9+ add 'Fixes: ... ' line in the comment --- include/linux/firmware/intel/stratix10-svc-client.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/firmware/intel/stratix10-svc-client.h b/include/linux/firmware/intel/stratix10-svc-client.h index a93d859..f843c6a 100644 --- a/include/linux/firmware/intel/stratix10-svc-client.h +++ b/include/linux/firmware/intel/stratix10-svc-client.h @@ -56,7 +56,7 @@ * COMMAND_RECONFIG_FLAG_PARTIAL: * Set to FPGA configuration type (full or partial). */ -#define COMMAND_RECONFIG_FLAG_PARTIAL 1 +#define COMMAND_RECONFIG_FLAG_PARTIAL 0 /** * Timeout settings for service clients: -- 2.7.4

3 years, 8 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2021