July 2020 - Linux-stable-mirror

+ fs-minix-check-return-value-of-sb_getblk.patch added to -mm tree

by Andrew Morton

The patch titled Subject: fs/minix: check return value of sb_getblk() has been added to the -mm tree. Its filename is fs-minix-check-return-value-of-sb_getblk.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/fs-minix-check-return-value-of-sb_… and later at http://ozlabs.org/~akpm/mmotm/broken-out/fs-minix-check-return-value-of-sb_… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Eric Biggers <ebiggers(a)google.com> Subject: fs/minix: check return value of sb_getblk() Patch series "fs/minix: fix syzbot bugs and set s_maxbytes". This series fixes all syzbot bugs in the minix filesystem: KASAN: null-ptr-deref Write in get_block KASAN: use-after-free Write in get_block KASAN: use-after-free Read in get_block WARNING in inc_nlink KMSAN: uninit-value in get_block WARNING in drop_nlink It also fixes the minix filesystem to set s_maxbytes correctly, so that userspace sees the correct behavior when exceeding the max file size. This patch (of 6): sb_getblk() can fail, so check its return value. This fixes a NULL pointer dereference. Originally from Qiujun Huang. Link: http://lkml.kernel.org/r/20200628060846.682158-1-ebiggers@kernel.org Link: http://lkml.kernel.org/r/20200628060846.682158-2-ebiggers@kernel.org Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Reported-by: syzbot+4a88b2b9dc280f47baf4(a)syzkaller.appspotmail.com Cc: Qiujun Huang <anenbupt(a)gmail.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/minix/itree_common.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/fs/minix/itree_common.c~fs-minix-check-return-value-of-sb_getblk +++ a/fs/minix/itree_common.c @@ -75,6 +75,7 @@ static int alloc_branch(struct inode *in int n = 0; int i; int parent = minix_new_block(inode); + int err = -ENOSPC; branch[0].key = cpu_to_block(parent); if (parent) for (n = 1; n < num; n++) { @@ -85,6 +86,11 @@ static int alloc_branch(struct inode *in break; branch[n].key = cpu_to_block(nr); bh = sb_getblk(inode->i_sb, parent); + if (!bh) { + minix_free_block(inode, nr); + err = -ENOMEM; + break; + } lock_buffer(bh); memset(bh->b_data, 0, bh->b_size); branch[n].bh = bh; @@ -103,7 +109,7 @@ static int alloc_branch(struct inode *in bforget(branch[i].bh); for (i = 0; i < n; i++) minix_free_block(inode, block_to_cpu(branch[i].key)); - return -ENOSPC; + return err; } static inline int splice_branch(struct inode *inode, _ Patches currently in -mm which might be from ebiggers(a)google.com are fs-minix-check-return-value-of-sb_getblk.patch fs-minix-dont-allow-getting-deleted-inodes.patch fs-minix-reject-too-large-maximum-file-size.patch fs-minix-set-s_maxbytes-correctly.patch fs-minix-fix-block-limit-check-for-v1-filesystems.patch fs-minix-remove-expected-error-message-in-block_to_path.patch

4 years, 5 months

1
0
0 0

[RFT PATCH] ia64: Fix build error with !COREDUMP

by Krzysztof Kozlowski

Fix linkage error when CONFIG_BINFMT_ELF is selected but CONFIG_COREDUMP is not: ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function `elf_core_write_extra_phdrs': elfcore.c:(.text+0x172): undefined reference to `dump_emit' ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function `elf_core_write_extra_data': elfcore.c:(.text+0x2b2): undefined reference to `dump_emit' Cc: <stable(a)vger.kernel.org> Fixes: 1fcccbac89f5 ("elf coredump: replace ELF_CORE_EXTRA_* macros by functions") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- Please let kbuild test it for a while before applying. I built it only on few configurations. This is similar fix to commit 42d91f612c87 ("um: Fix build error and kconfig for i386") although I put different fixes tag - the commit which introduced this part of code. --- arch/ia64/kernel/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/kernel/Makefile b/arch/ia64/kernel/Makefile index 1a8df6669eee..18d6008b151f 100644 --- a/arch/ia64/kernel/Makefile +++ b/arch/ia64/kernel/Makefile @@ -41,7 +41,7 @@ obj-y += esi_stub.o # must be in kernel proper endif obj-$(CONFIG_INTEL_IOMMU) += pci-dma.o -obj-$(CONFIG_BINFMT_ELF) += elfcore.o +obj-$(CONFIG_ELF_CORE) += elfcore.o # fp_emulate() expects f2-f5,f16-f31 to contain the user-level state. CFLAGS_traps.o += -mfixed-range=f2-f5,f16-f31 -- 2.17.1

4 years, 5 months

1
1
0 0

[PATCH v2 1/2] i2c: imx: Fix PM runtime inbalance in probe error path

by Krzysztof Kozlowski

When pm_runtime_get_sync() fails in probe(), the error path should not call pm_runtime_put_noidle(). This would lead to inbalance in usage_count. Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- Changes since v1: 1. New patch --- drivers/i2c/busses/i2c-imx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index 0ab5381aa012..6e45958565d1 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -1239,8 +1239,8 @@ static int i2c_imx_probe(struct platform_device *pdev) clk_notifier_unregister: clk_notifier_unregister(i2c_imx->clk, &i2c_imx->clk_change_nb); -rpm_disable: pm_runtime_put_noidle(&pdev->dev); +rpm_disable: pm_runtime_disable(&pdev->dev); pm_runtime_set_suspended(&pdev->dev); pm_runtime_dont_use_autosuspend(&pdev->dev); -- 2.7.4

4 years, 5 months

1
3
0 0

Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

by lepton

On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson <chris(a)chris-wilson.co.uk> wrote: > > Quoting lepton (2020-07-07 18:05:21) > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson <chris(a)chris-wilson.co.uk> wrote: > > > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > > allow direct operations like mmap() assuming it behaves as backed by a > > > shmemfs inode. When imported from a dmabuf, the obj->pages are > > > not always meaningful and the shmemfs backing store misleading. > > > > > > Note, that regular mmap access to a vgem bo is via the dumb buffer API, > > > and that rejects attempts to mmap an imported dmabuf, > > What do you mean by "regular mmap access" here? It looks like vgem is > > using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call > > drm_gem_dumb_map_offset > > As I too found out, and so had to correct my story telling. > > By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer > API] as opposed to mmap() via an exported dma-buf fd. I had to look at > igt to see how it was being used. Now it seems your fix is to disable "regular mmap" on imported dma buf for vgem. I am not really a graphic guy, but then the api looks like: for a gem handle, user space has to guess to find out the way to mmap it. If user space guess wrong, then it will fail to mmap. Is this the expected way for people to handle gpu buffer? > -Chris

4 years, 5 months

1
0
0 0

patch "usb: chipidea: core: add wakeup support for extcon" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: chipidea: core: add wakeup support for extcon 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-linus 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 hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 876d4e1e8298ad1f94d9e9392fc90486755437b4 Mon Sep 17 00:00:00 2001 From: Peter Chen <peter.chen(a)nxp.com> Date: Tue, 7 Jul 2020 14:06:01 +0800 Subject: usb: chipidea: core: add wakeup support for extcon If wakeup event occurred by extcon event, it needs to call ci_irq again since the first ci_irq calling at extcon notifier only wakes up controller, but do noop for event handling, it causes the extcon use case can't work well from low power mode. Cc: <stable(a)vger.kernel.org> Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID detect") Reported-by: Philippe Schenker <philippe.schenker(a)toradex.com> Tested-by: Philippe Schenker <philippe.schenker(a)toradex.com> Signed-off-by: Peter Chen <peter.chen(a)nxp.com> Link: https://lore.kernel.org/r/20200707060601.31907-2-peter.chen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/chipidea/core.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 9a7c53d09ab4..bb133245beed 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -1243,6 +1243,29 @@ static void ci_controller_suspend(struct ci_hdrc *ci) enable_irq(ci->irq); } +/* + * Handle the wakeup interrupt triggered by extcon connector + * We need to call ci_irq again for extcon since the first + * interrupt (wakeup int) only let the controller be out of + * low power mode, but not handle any interrupts. + */ +static void ci_extcon_wakeup_int(struct ci_hdrc *ci) +{ + struct ci_hdrc_cable *cable_id, *cable_vbus; + u32 otgsc = hw_read_otgsc(ci, ~0); + + cable_id = &ci->platdata->id_extcon; + cable_vbus = &ci->platdata->vbus_extcon; + + if (!IS_ERR(cable_id->edev) && ci->is_otg && + (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) + ci_irq(ci->irq, ci); + + if (!IS_ERR(cable_vbus->edev) && ci->is_otg && + (otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) + ci_irq(ci->irq, ci); +} + static int ci_controller_resume(struct device *dev) { struct ci_hdrc *ci = dev_get_drvdata(dev); @@ -1275,6 +1298,7 @@ static int ci_controller_resume(struct device *dev) enable_irq(ci->irq); if (ci_otg_is_fsm_mode(ci)) ci_otg_fsm_wakeup_by_srp(ci); + ci_extcon_wakeup_int(ci); } return 0; -- 2.27.0

4 years, 5 months

1
0
0 0

[PATCH] blk-mq: consider non-idle request as "inflight" in blk_mq_rq_inflight()

by Mike Snitzer

From: Ming Lei <ming.lei(a)redhat.com> dm-multipath is the only user of blk_mq_queue_inflight(). When dm-multipath calls blk_mq_queue_inflight() to check if it has outstanding IO it can get a false negative. The reason for this is blk_mq_rq_inflight() doesn't consider requests that are no longer MQ_RQ_IN_FLIGHT but that are now MQ_RQ_COMPLETE (->complete isn't called or finished yet) as "inflight". This causes request-based dm-multipath's dm_wait_for_completion() to return before all outstanding dm-multipath requests have actually completed. This breaks DM multipath's suspend functionality because blk-mq requests complete after DM's suspend has finished -- which shouldn't happen. Fix this by considering any request not in the MQ_RQ_IDLE state (so either MQ_RQ_COMPLETE or MQ_RQ_IN_FLIGHT) as "inflight" in blk_mq_rq_inflight(). Fixes: 3c94d83cb3526 ("blk-mq: change blk_mq_queue_busy() to blk_mq_queue_inflight()") Cc: stable(a)vger.kernel.org Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> --- block/blk-mq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 4f57d27bfa73..e6219c27fc65 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -828,10 +828,10 @@ static bool blk_mq_rq_inflight(struct blk_mq_hw_ctx *hctx, struct request *rq, void *priv, bool reserved) { /* - * If we find a request that is inflight and the queue matches, + * If we find a request that isn't idle and the queue matches, * we know the queue is busy. Return false to stop the iteration. */ - if (rq->state == MQ_RQ_IN_FLIGHT && rq->q == hctx->queue) { + if (blk_mq_request_started(rq) && rq->q == hctx->queue) { bool *busy = priv; *busy = true; -- 2.15.0

4 years, 5 months

2
1
0 0

WTF: patch "[PATCH] efi: Make it possible to disable efivar_ssdt entirely" was seriously submitted to be applied to the 5.7-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 5.7-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 435d1a471598752446a72ad1201b3c980526d869 Mon Sep 17 00:00:00 2001 From: Peter Jones <pjones(a)redhat.com> Date: Mon, 15 Jun 2020 16:24:08 -0400 Subject: [PATCH] efi: Make it possible to disable efivar_ssdt entirely In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables are tied to specific Kconfig options. Currently this is not the case for modifying the ACPI SSDT via the efivar_ssdt kernel command line option and associated EFI variable. This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults disabled, in order to allow enabling or disabling that feature during the build. Cc: <stable(a)vger.kernel.org> Signed-off-by: Peter Jones <pjones(a)redhat.com> Link: https://lore.kernel.org/r/20200615202408.2242614-1-pjones@redhat.com Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig index e6fc022bc87e..3939699e62fe 100644 --- a/drivers/firmware/efi/Kconfig +++ b/drivers/firmware/efi/Kconfig @@ -278,3 +278,14 @@ config EFI_EARLYCON depends on SERIAL_EARLYCON && !ARM && !IA64 select FONT_SUPPORT select ARCH_USE_MEMREMAP_PROT + +config EFI_CUSTOM_SSDT_OVERLAYS + bool "Load custom ACPI SSDT overlay from an EFI variable" + depends on EFI_VARS && ACPI + default ACPI_TABLE_UPGRADE + help + Allow loading of an ACPI SSDT overlay from an EFI variable specified + by a kernel command line option. + + See Documentation/admin-guide/acpi/ssdt-overlays.rst for more + information. diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index edc5d36caf54..5114cae4ec97 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -189,7 +189,7 @@ static void generic_ops_unregister(void) efivars_unregister(&generic_efivars); } -#if IS_ENABLED(CONFIG_ACPI) +#ifdef CONFIG_EFI_CUSTOM_SSDT_OVERLAYS #define EFIVAR_SSDT_NAME_MAX 16 static char efivar_ssdt[EFIVAR_SSDT_NAME_MAX] __initdata; static int __init efivar_ssdt_setup(char *str)

4 years, 5 months

3
5
0 0

[PATCH] dm zoned: assign max_io_len correctly

by Damien Le Moal

From: Hou Tao <houtao1(a)huawei.com> commit 7b2377486767503d47265e4d487a63c651f6b55d upstream. The unit of max_io_len is sector instead of byte (spotted through code review), so fix it. Fixes: 3b1a94c88b79 ("dm zoned: drive-managed zoned block device target") Cc: stable(a)vger.kernel.org Signed-off-by: Hou Tao <houtao1(a)huawei.com> Reviewed-by: Damien Le Moal <damien.lemoal(a)wdc.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> --- drivers/md/dm-zoned-target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c index f4f83d39b3dc..29881fea6acb 100644 --- a/drivers/md/dm-zoned-target.c +++ b/drivers/md/dm-zoned-target.c @@ -790,7 +790,7 @@ static int dmz_ctr(struct dm_target *ti, unsigned int argc, char **argv) } /* Set target (no write same support) */ - ti->max_io_len = dev->zone_nr_sectors << 9; + ti->max_io_len = dev->zone_nr_sectors; ti->num_flush_bios = 1; ti->num_discard_bios = 1; ti->num_write_zeroes_bios = 1; -- 2.26.2

4 years, 5 months

3
5
0 0

[PATCH] x86/resctrl: Fix memory bandwidth counter width for AMD

by Babu Moger

[ Upstream commit 2c18bd525c47f882f033b0a813ecd09c93e1ecdf ] Memory bandwidth is calculated reading the monitoring counter at two intervals and calculating the delta. It is the software’s responsibility to read the count often enough to avoid having the count roll over _twice_ between reads. The current code hardcodes the bandwidth monitoring counter's width to 24 bits for AMD. This is due to default base counter width which is 24. Currently, AMD does not implement the CPUID 0xF.[ECX=1]:EAX to adjust the counter width. But, the AMD hardware supports much wider bandwidth counter with the default width of 44 bits. Kernel reads these monitoring counters every 1 second and adjusts the counter value for overflow. With 24 bits and scale value of 64 for AMD, it can only measure up to 1GB/s without overflowing. For the rates above 1GB/s this will fail to measure the bandwidth. Fix the issue setting the default width to 44 bits by adjusting the offset. AMD future products will implement CPUID 0xF.[ECX=1]:EAX. [ bp: Let the line stick out and drop {}-brackets around a single statement. ] Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Babu Moger <babu.moger(a)amd.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Link: https://lkml.kernel.org/r/159129975546.62538.5656031125604254041.stgit@napl… --- Note: This commit is already queued for 5.7 stable kernel. Backporting it t 5.6 stable and older kernels now. Had to make some changes in data structure to make it work on older kernels arch/x86/kernel/cpu/resctrl/core.c | 2 ++ arch/x86/kernel/cpu/resctrl/internal.h | 3 +++ arch/x86/kernel/cpu/resctrl/monitor.c | 3 ++- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 89049b343c7a..5fb0b84cda30 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -260,6 +260,7 @@ static bool __get_mem_config_intel(struct rdt_resource *r) r->num_closid = edx.split.cos_max + 1; r->membw.max_delay = eax.split.max_delay + 1; r->default_ctrl = MAX_MBA_BW; + r->membw.mbm_width = MBM_CNTR_WIDTH; if (ecx & MBA_IS_LINEAR) { r->membw.delay_linear = true; r->membw.min_bw = MAX_MBA_BW - r->membw.max_delay; @@ -289,6 +290,7 @@ static bool __rdt_get_mem_config_amd(struct rdt_resource *r) /* AMD does not use delay */ r->membw.delay_linear = false; + r->membw.mbm_width = MBM_CNTR_WIDTH_AMD; r->membw.min_bw = 0; r->membw.bw_gran = 1; /* Max value is 2048, Data width should be 4 in decimal */ diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h index 181c992f448c..2cfc4f5aceee 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -32,6 +32,7 @@ #define CQM_LIMBOCHECK_INTERVAL 1000 #define MBM_CNTR_WIDTH 24 +#define MBM_CNTR_WIDTH_AMD 44 #define MBM_OVERFLOW_INTERVAL 1000 #define MAX_MBA_BW 100u #define MBA_IS_LINEAR 0x4 @@ -368,6 +369,7 @@ struct rdt_cache { * @min_bw: Minimum memory bandwidth percentage user can request * @bw_gran: Granularity at which the memory bandwidth is allocated * @delay_linear: True if memory B/W delay is in linear scale + * @mbm_width: memory B/W monitor counter width * @mba_sc: True if MBA software controller(mba_sc) is enabled * @mb_map: Mapping of memory B/W percentage to memory B/W delay */ @@ -376,6 +378,7 @@ struct rdt_membw { u32 min_bw; u32 bw_gran; u32 delay_linear; + u32 mbm_width; bool mba_sc; u32 *mb_map; }; diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index 773124b0e18a..0cf4f87f6012 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -216,8 +216,9 @@ void free_rmid(u32 rmid) static u64 mbm_overflow_count(u64 prev_msr, u64 cur_msr) { - u64 shift = 64 - MBM_CNTR_WIDTH, chunks; + u64 shift, chunks; + shift = 64 - rdt_resources_all[RDT_RESOURCE_MBA].membw.mbm_width; chunks = (cur_msr << shift) - (prev_msr << shift); return chunks >>= shift; }

4 years, 5 months

2
1
0 0

Re: [PATCH v4.10] netfilter: nf_conntrack_h323: lost .data_len definition for Q.931/ipv6

by Pablo Neira Ayuso

CC'ing stable(a)vger.kernel.org On Tue, Jun 09, 2020 at 10:53:22AM +0300, Vasily Averin wrote: > Could you please push this patch into stable@? > it fixes memory corruption in kernels v3.5 .. v4.10 > > Lost .data_len definition leads to write beyond end of > struct nf_ct_h323_master. Usually it corrupts following > struct nf_conn_nat, however if nat is not loaded it corrupts > following slab object. > > In mainline this problem went away in v4.11, > after commit 9f0f3ebeda47 ("netfilter: helpers: remove data_len usage > for inkernel helpers") however many stable kernels are still affected. -stable maintainers of: 3.16, 4.4 and 4.9. Please apply this patch, thanks. > cc: stable(a)vger.kernel.org > Fixes: 1afc56794e03 ("netfilter: nf_ct_helper: implement variable length helper private data") # v3.5 > Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com> > --- > net/netfilter/nf_conntrack_h323_main.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c > index f65d93639d12..29fe1e7eac88 100644 > --- a/net/netfilter/nf_conntrack_h323_main.c > +++ b/net/netfilter/nf_conntrack_h323_main.c > @@ -1225,6 +1225,7 @@ static struct nf_conntrack_helper nf_conntrack_helper_q931[] __read_mostly = { > { > .name = "Q.931", > .me = THIS_MODULE, > + .data_len = sizeof(struct nf_ct_h323_master), > .tuple.src.l3num = AF_INET6, > .tuple.src.u.tcp.port = cpu_to_be16(Q931_PORT), > .tuple.dst.protonum = IPPROTO_TCP, > -- > 2.17.1 >

4 years, 5 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2020