From: Yang Yingliang yangyingliang@huawei.com
hulk inclusion category: bugfix bugzilla: 179898 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2018-12928
---------------------------
It will cause a null-ptr-deref in hfs_find_init() in fuzz test.
[ 107.092729] hfs: continuing without an alternate MDB [ 107.097632] general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KASAN PTI [ 107.104679] KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] [ 107.109100] CPU: 0 PID: 379 Comm: hfs_inject Not tainted 5.7.0-rc7-00001-g24627f5f2973 #897 [ 107.114142] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 107.121095] RIP: 0010:hfs_find_init+0x72/0x170 [ 107.123609] Code: c1 ea 03 80 3c 02 00 0f 85 e6 00 00 00 4c 8d 65 40 48 c7 43 18 00 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e a5 00 00 00 8b 45 40 be c0 0c [ 107.134660] RSP: 0018:ffff88810291f3f8 EFLAGS: 00010202 [ 107.137897] RAX: dffffc0000000000 RBX: ffff88810291f468 RCX: 1ffff110175cdf05 [ 107.141874] RDX: 0000000000000008 RSI: ffff88810291f468 RDI: ffff88810291f480 [ 107.145844] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020381013 [ 107.149431] R10: ffff88810291f500 R11: ffffed1020381012 R12: 0000000000000040 [ 107.152315] R13: 0000000000000000 R14: ffff888101c0814a R15: ffff88810291f468 [ 107.155464] FS: 00000000009ea880(0000) GS:ffff88810c600000(0000) knlGS:0000000000000000 [ 107.159795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 107.162987] CR2: 00005605a19dd284 CR3: 0000000103a0c006 CR4: 0000000000020ef0 [ 107.166665] Call Trace: [ 107.167969] ? find_held_lock+0x33/0x1c0 [ 107.169972] hfs_ext_read_extent+0x16b/0xb00 [ 107.172092] ? create_page_buffers+0x14e/0x1b0 [ 107.174303] ? hfs_free_extents+0x280/0x280 [ 107.176437] ? lock_downgrade+0x730/0x730 [ 107.178272] hfs_get_block+0x496/0x8a0 [ 107.179972] block_read_full_page+0x241/0x8d0 [ 107.181971] ? hfs_extend_file+0xae0/0xae0 [ 107.183814] ? end_buffer_async_read_io+0x10/0x10 [ 107.185954] ? add_to_page_cache_lru+0x13f/0x1f0 [ 107.188006] ? add_to_page_cache_locked+0x10/0x10 [ 107.190175] do_read_cache_page+0xc6a/0x1180 [ 107.192096] ? generic_file_read_iter+0x4c0/0x4c0 [ 107.194234] ? hfs_btree_open+0x408/0x1000 [ 107.196068] ? lock_downgrade+0x730/0x730 [ 107.197926] ? wake_bit_function+0x180/0x180 [ 107.199845] ? lockdep_init_map_waits+0x267/0x7c0 [ 107.201895] hfs_btree_open+0x455/0x1000 [ 107.203479] hfs_mdb_get+0x122c/0x1ae8 [ 107.205065] ? hfs_mdb_put+0x350/0x350 [ 107.206590] ? queue_work_node+0x260/0x260 [ 107.208309] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 107.210227] ? lockdep_init_map_waits+0x267/0x7c0 [ 107.212144] ? lockdep_init_map_waits+0x267/0x7c0 [ 107.213979] hfs_fill_super+0x9ba/0x1280 [ 107.215444] ? bdev_name.isra.9+0xf1/0x2b0 [ 107.217028] ? hfs_remount+0x190/0x190 [ 107.218428] ? pointer+0x5da/0x710 [ 107.219745] ? file_dentry_name+0xf0/0xf0 [ 107.221262] ? mount_bdev+0xd1/0x330 [ 107.222592] ? vsnprintf+0x7bd/0x1250 [ 107.224007] ? pointer+0x710/0x710 [ 107.225332] ? down_write+0xe5/0x160 [ 107.226698] ? hfs_remount+0x190/0x190 [ 107.228120] ? snprintf+0x91/0xc0 [ 107.229388] ? vsprintf+0x10/0x10 [ 107.230628] ? sget+0x3af/0x4a0 [ 107.231848] ? hfs_remount+0x190/0x190 [ 107.233300] mount_bdev+0x26e/0x330 [ 107.234611] ? hfs_statfs+0x540/0x540 [ 107.236015] legacy_get_tree+0x101/0x1f0 [ 107.237431] ? security_capable+0x58/0x90 [ 107.238832] vfs_get_tree+0x89/0x2d0 [ 107.240082] ? ns_capable_common+0x5c/0xd0 [ 107.241521] do_mount+0xd8a/0x1720 [ 107.242727] ? lock_downgrade+0x730/0x730 [ 107.244116] ? copy_mount_string+0x20/0x20 [ 107.245557] ? _copy_from_user+0xbe/0x100 [ 107.246967] ? memdup_user+0x47/0x70 [ 107.248212] __x64_sys_mount+0x162/0x1b0 [ 107.249537] do_syscall_64+0xa5/0x4f0 [ 107.250742] entry_SYSCALL_64_after_hwframe+0x49/0xb3 [ 107.252369] RIP: 0033:0x44e8ea [ 107.253360] Code: 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 [ 107.259240] RSP: 002b:00007ffd910e4c28 EFLAGS: 00000207 ORIG_RAX: 00000000000000a5 [ 107.261668] RAX: ffffffffffffffda RBX: 0000000000400400 RCX: 000000000044e8ea [ 107.263920] RDX: 000000000049321e RSI: 0000000000493222 RDI: 00007ffd910e4d00 [ 107.266177] RBP: 00007ffd910e5d10 R08: 0000000000000000 R09: 000000000000000a [ 107.268451] R10: 0000000000000001 R11: 0000000000000207 R12: 0000000000401c40 [ 107.270721] R13: 0000000000000000 R14: 00000000006ba018 R15: 0000000000000000 [ 107.273025] Modules linked in: [ 107.274029] Dumping ftrace buffer: [ 107.275121] (ftrace buffer empty) [ 107.276370] ---[ end trace c5e0b9d684f3570e ]---
We need check tree in hfs_find_init().
https://lore.kernel.org/linux-fsdevel/20180419024358.GA5215@bombadil.infrade... https://marc.info/?l=linux-fsdevel&m=152406881024567&w=2 References: CVE-2018-12928 Signed-off-by: Yang Yingliang yangyingliang@huawei.com Reviewed-by: Jason Yan yanaijie@huawei.com Signed-off-by: Yang Yingliang yangyingliang@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- fs/hfs/bfind.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/fs/hfs/bfind.c b/fs/hfs/bfind.c index ef9498a6e88a..ae44c8fa86ec 100644 --- a/fs/hfs/bfind.c +++ b/fs/hfs/bfind.c @@ -16,6 +16,8 @@ int hfs_find_init(struct hfs_btree *tree, struct hfs_find_data *fd) { void *ptr;
+ if (!tree) + return -EINVAL; fd->tree = tree; fd->bnode = NULL; ptr = kmalloc(tree->max_key_len * 2 + 4, GFP_KERNEL);
From: Russell King rmk+kernel@armlinux.org.uk
mainline inclusion from mainline-5.13-rc1 commit 298a58e165e447ccfaae35fe9f651f9d7e15166f bugzilla: 177765 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-32078
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
--------------------------------
Remove the personal server platform, as that has had an array overrun issue identified. It is believed that no one is using this code.
Signed-off-by: Russell King rmk+kernel@armlinux.org.uk
Conflicts: arch/arm/mach-footbridge/personal-pci.c Signed-off-by: Chen Jun chenjun102@huawei.com --- arch/arm/configs/footbridge_defconfig | 1 - arch/arm/mach-footbridge/Kconfig | 21 --------- arch/arm/mach-footbridge/Makefile | 2 - arch/arm/mach-footbridge/personal-pci.c | 57 ------------------------- arch/arm/mach-footbridge/personal.c | 25 ----------- 5 files changed, 106 deletions(-) delete mode 100644 arch/arm/mach-footbridge/personal-pci.c delete mode 100644 arch/arm/mach-footbridge/personal.c
diff --git a/arch/arm/configs/footbridge_defconfig b/arch/arm/configs/footbridge_defconfig index 3a7938f244e5..2aa3ebeb89d7 100644 --- a/arch/arm/configs/footbridge_defconfig +++ b/arch/arm/configs/footbridge_defconfig @@ -7,7 +7,6 @@ CONFIG_EXPERT=y CONFIG_MODULES=y CONFIG_ARCH_FOOTBRIDGE=y CONFIG_ARCH_CATS=y -CONFIG_ARCH_PERSONAL_SERVER=y CONFIG_ARCH_EBSA285_HOST=y CONFIG_ARCH_NETWINDER=y CONFIG_LEDS=y diff --git a/arch/arm/mach-footbridge/Kconfig b/arch/arm/mach-footbridge/Kconfig index 844aa585b966..728aff93fba9 100644 --- a/arch/arm/mach-footbridge/Kconfig +++ b/arch/arm/mach-footbridge/Kconfig @@ -16,27 +16,6 @@ config ARCH_CATS
Saying N will reduce the size of the Footbridge kernel.
-config ARCH_PERSONAL_SERVER - bool "Compaq Personal Server" - select FOOTBRIDGE_HOST - select ISA - select ISA_DMA - select FORCE_PCI - help - Say Y here if you intend to run this kernel on the Compaq - Personal Server. - - Saying N will reduce the size of the Footbridge kernel. - - The Compaq Personal Server is not available for purchase. - There are no product plans beyond the current research - prototypes at this time. Information is available at: - - http://www.crl.hpl.hp.com/projects/personalserver/ - - If you have any questions or comments about the Compaq Personal - Server, send e-mail to skiff@crl.dec.com. - config ARCH_EBSA285_ADDIN bool "EBSA285 (addin mode)" select ARCH_EBSA285 diff --git a/arch/arm/mach-footbridge/Makefile b/arch/arm/mach-footbridge/Makefile index a09f1041f141..6262993c0555 100644 --- a/arch/arm/mach-footbridge/Makefile +++ b/arch/arm/mach-footbridge/Makefile @@ -11,12 +11,10 @@ pci-y += dc21285.o pci-$(CONFIG_ARCH_CATS) += cats-pci.o pci-$(CONFIG_ARCH_EBSA285_HOST) += ebsa285-pci.o pci-$(CONFIG_ARCH_NETWINDER) += netwinder-pci.o -pci-$(CONFIG_ARCH_PERSONAL_SERVER) += personal-pci.o
obj-$(CONFIG_ARCH_CATS) += cats-hw.o isa-timer.o obj-$(CONFIG_ARCH_EBSA285) += ebsa285.o dc21285-timer.o obj-$(CONFIG_ARCH_NETWINDER) += netwinder-hw.o isa-timer.o -obj-$(CONFIG_ARCH_PERSONAL_SERVER) += personal.o dc21285-timer.o
obj-$(CONFIG_PCI) +=$(pci-y)
diff --git a/arch/arm/mach-footbridge/personal-pci.c b/arch/arm/mach-footbridge/personal-pci.c deleted file mode 100644 index 9d19aa98a663..000000000000 --- a/arch/arm/mach-footbridge/personal-pci.c +++ /dev/null @@ -1,57 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0 -/* - * linux/arch/arm/mach-footbridge/personal-pci.c - * - * PCI bios-type initialisation for PCI machines - * - * Bits taken from various places. - */ -#include <linux/kernel.h> -#include <linux/pci.h> -#include <linux/init.h> - -#include <asm/irq.h> -#include <asm/mach/pci.h> -#include <asm/mach-types.h> - -static int irqmap_personal_server[] = { - IRQ_IN0, IRQ_IN1, IRQ_IN2, IRQ_IN3, 0, 0, 0, - IRQ_DOORBELLHOST, IRQ_DMA1, IRQ_DMA2, IRQ_PCI -}; - -static int personal_server_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) -{ - unsigned char line; - - pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &line); - - if (line > 0x40 && line <= 0x5f) { - /* line corresponds to the bit controlling this interrupt - * in the footbridge. Ignore the first 8 interrupt bits, - * look up the rest in the map. IN0 is bit number 8 - */ - return irqmap_personal_server[(line & 0x1f) - 8]; - } else if (line == 0) { - /* no interrupt */ - return 0; - } else - return irqmap_personal_server[(line - 1) & 3]; -} - -static struct hw_pci personal_server_pci __initdata = { - .map_irq = personal_server_map_irq, - .nr_controllers = 1, - .ops = &dc21285_ops, - .setup = dc21285_setup, - .preinit = dc21285_preinit, - .postinit = dc21285_postinit, -}; - -static int __init personal_pci_init(void) -{ - if (machine_is_personal_server()) - pci_common_init(&personal_server_pci); - return 0; -} - -subsys_initcall(personal_pci_init); diff --git a/arch/arm/mach-footbridge/personal.c b/arch/arm/mach-footbridge/personal.c deleted file mode 100644 index ca715754fc00..000000000000 --- a/arch/arm/mach-footbridge/personal.c +++ /dev/null @@ -1,25 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0 -/* - * linux/arch/arm/mach-footbridge/personal.c - * - * Personal server (Skiff) machine fixup - */ -#include <linux/init.h> -#include <linux/spinlock.h> - -#include <asm/hardware/dec21285.h> -#include <asm/mach-types.h> - -#include <asm/mach/arch.h> - -#include "common.h" - -MACHINE_START(PERSONAL_SERVER, "Compaq-PersonalServer") - /* Maintainer: Jamey Hicks / George France */ - .atag_offset = 0x100, - .map_io = footbridge_map_io, - .init_irq = footbridge_init_irq, - .init_time = footbridge_timer_init, - .restart = footbridge_restart, -MACHINE_END -
From: Marcelo Ricardo Leitner marcelo.leitner@gmail.com
mainline inclusion from mainline-5.14-rc1 commit b6ffe7671b24689c09faa5675dd58f93758a97ae bugzilla: 177765 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-3655
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
--------------------------------
In one of the fallbacks that SCTP has for identifying an association for an incoming packet, it looks for AddIp chunk (from ASCONF) and take a peek. Thing is, at this stage nothing was validating that the chunk actually had enough content for that, allowing the peek to happen over uninitialized memory.
Similar check already exists in actual asconf handling in sctp_verify_asconf().
Signed-off-by: Marcelo Ricardo Leitner marcelo.leitner@gmail.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Yue Haibing yuehaibing@huawei.com Reviewed-by: Xiu Jianfeng xiujianfeng@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- net/sctp/input.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/net/sctp/input.c b/net/sctp/input.c index ddb5b5c2550e..49c49a4d203f 100644 --- a/net/sctp/input.c +++ b/net/sctp/input.c @@ -1168,6 +1168,9 @@ static struct sctp_association *__sctp_rcv_asconf_lookup( union sctp_addr_param *param; union sctp_addr paddr;
+ if (ntohs(ch->length) < sizeof(*asconf) + sizeof(struct sctp_paramhdr)) + return NULL; + /* Skip over the ADDIP header and find the Address parameter */ param = (union sctp_addr_param *)(asconf + 1);
From: Marcelo Ricardo Leitner marcelo.leitner@gmail.com
mainline inclusion from mainline-5.14-rc1 commit ef6c8d6ccf0c1dccdda092ebe8782777cd7803c9 bugzilla: 177765 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-3655
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
--------------------------------
When SCTP handles an INIT chunk, it calls for example: sctp_sf_do_5_1B_init sctp_verify_init sctp_verify_param sctp_process_init sctp_process_param handling of SCTP_PARAM_SET_PRIMARY
sctp_verify_init() wasn't doing proper size validation and neither the later handling, allowing it to work over the chunk itself, possibly being uninitialized memory.
Signed-off-by: Marcelo Ricardo Leitner marcelo.leitner@gmail.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Yue Haibing yuehaibing@huawei.com Reviewed-by: Xiu Jianfeng xiujianfeng@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- net/sctp/sm_make_chunk.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 7411fa442821..fa0d96320baa 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -2150,9 +2150,16 @@ static enum sctp_ierror sctp_verify_param(struct net *net, break;
case SCTP_PARAM_SET_PRIMARY: - if (ep->asconf_enable) - break; - goto unhandled; + if (!ep->asconf_enable) + goto unhandled; + + if (ntohs(param.p->length) < sizeof(struct sctp_addip_param) + + sizeof(struct sctp_paramhdr)) { + sctp_process_inv_paramlength(asoc, param.p, + chunk, err_chunk); + retval = SCTP_IERROR_ABORT; + } + break;
case SCTP_PARAM_HOST_NAME_ADDRESS: /* Tell the peer, we won't support this param. */
From: Seunghun Han kkamagui@gmail.com
hulk inclusion category: bugfix bugzilla: 180973 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2017-13693
-------------------------------------------------
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination is occurred due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
[ 0.585957] ACPI: Added _OSI(Module Device) [ 0.587218] ACPI: Added _OSI(Processor Device) [ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) [ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) [ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) [ 0.597858] ACPI: Unable to start the ACPI Interpreter [ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects [ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 [ 0.605159] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 0.609177] Call Trace: [ 0.610063] ? dump_stack+0x5c/0x81 [ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 [ 0.613906] ? acpi_os_delete_cache+0xa/0x10 [ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b [ 0.619293] ? acpi_terminate+0xa/0x14 [ 0.620394] ? acpi_init+0x2af/0x34f [ 0.621616] ? __class_create+0x4c/0x80 [ 0.623412] ? video_setup+0x7f/0x7f [ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 [ 0.625861] ? do_one_initcall+0x4e/0x1a0 [ 0.627513] ? kernel_init_freeable+0x19e/0x21f [ 0.628972] ? rest_init+0x80/0x80 [ 0.630043] ? kernel_init+0xa/0x100 [ 0.631084] ? ret_from_fork+0x25/0x30 [ 0.633343] vgaarb: loaded [ 0.635036] EDAC MC: Ver: 3.0.0 [ 0.638601] PCI: Probing PCI hardware [ 0.639833] PCI host bridge to bus 0000:00 [ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Signed-off-by: Seunghun Han kkamagui@gmail.com Signed-off-by: Yang Yingliang yangyingliang@huawei.com Reviewed-by: Hanjun Guo guohanjun@huawei.com Signed-off-by: Yang Yingliang yangyingliang@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Xiu Jianfeng xiujianfeng@huawei.com Reviewed-by: Hanjun Guo guohanjun@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- drivers/acpi/acpica/dsutils.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/dsutils.c b/drivers/acpi/acpica/dsutils.c index fb9ed5e1da89..2bdae8a25e08 100644 --- a/drivers/acpi/acpica/dsutils.c +++ b/drivers/acpi/acpica/dsutils.c @@ -668,6 +668,8 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, union acpi_parse_object *arguments[ACPI_OBJ_NUM_OPERANDS]; u32 arg_count = 0; u32 index = walk_state->num_operands; + u32 prev_num_operands = walk_state->num_operands; + u32 new_num_operands; u32 i;
ACPI_FUNCTION_TRACE_PTR(ds_create_operands, first_arg); @@ -696,6 +698,7 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state,
/* Create the interpreter arguments, in reverse order */
+ new_num_operands = index; index--; for (i = 0; i < arg_count; i++) { arg = arguments[index]; @@ -720,7 +723,11 @@ acpi_ds_create_operands(struct acpi_walk_state *walk_state, * pop everything off of the operand stack and delete those * objects */ - acpi_ds_obj_stack_pop_and_delete(arg_count, walk_state); + walk_state->num_operands = i; + acpi_ds_obj_stack_pop_and_delete(new_num_operands, walk_state); + + /* Restore operand count */ + walk_state->num_operands = prev_num_operands;
ACPI_EXCEPTION((AE_INFO, status, "While creating Arg %u", index)); return_ACPI_STATUS(status);
From: Seunghun Han kkamagui@gmail.com
hulk inclusion category: bugfix bugzilla: 180974 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2017-13694
-------------------------------------------------
I'm Seunghun Han, and I work for National Security Research Institute of South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases.
Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30
I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size.
I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function.
Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x34f [ 0.392000] ? __class_create+0x4c/0x80 [ 0.392000] ? video_setup+0x7f/0x7f [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? do_one_initcall+0x4e/0x1a0 [ 0.392000] ? kernel_init_freeable+0x189/0x20a [ 0.392000] ? rest_init+0xc0/0xc0 [ 0.392000] ? kernel_init+0xa/0x100 [ 0.392000] ? ret_from_fork+0x25/0x30
When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling acpi_terminate() function. The function calls acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_ cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache).
But the deletion codes in acpi_ut_delete_caches() function only delete slab caches using kmem_cache_destroy() function, therefore the cache objects should be flushed before acpi_ut_delete_caches() function.
“Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse function, acpi_ps_parse_loop(). The function should have flush codes to handle an error state due to invalid AML codes.
This cache leak has a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR.
To fix ACPI cache leak for enhancing security, I made a patch which has flush codes in acpi_ps_parse_loop() function.
I hope that this patch improves the security of Linux kernel.
Thank you.
Signed-off-by: Seunghun Han kkamagui@gmail.com Signed-off-by: Yang Yingliang yangyingliang@huawei.com Reviewed-by: Hanjun Guo guohanjun@huawei.com Signed-off-by: Yang Yingliang yangyingliang@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Hanjun Guo guohanjun@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- drivers/acpi/acpica/psobject.c | 53 ++++++++++------------------------ 1 file changed, 16 insertions(+), 37 deletions(-)
diff --git a/drivers/acpi/acpica/psobject.c b/drivers/acpi/acpica/psobject.c index 2480c26c5171..b6c87898bbd8 100644 --- a/drivers/acpi/acpica/psobject.c +++ b/drivers/acpi/acpica/psobject.c @@ -636,7 +636,8 @@ acpi_status acpi_ps_complete_final_op(struct acpi_walk_state *walk_state, union acpi_parse_object *op, acpi_status status) { - acpi_status status2; + acpi_status return_status = AE_OK; + u8 ascending = TRUE;
ACPI_FUNCTION_TRACE_PTR(ps_complete_final_op, walk_state);
@@ -650,7 +651,8 @@ acpi_ps_complete_final_op(struct acpi_walk_state *walk_state, op)); do { if (op) { - if (walk_state->ascending_callback != NULL) { + if (ascending && + walk_state->ascending_callback != NULL) { walk_state->op = op; walk_state->op_info = acpi_ps_get_opcode_info(op->common. @@ -672,49 +674,26 @@ acpi_ps_complete_final_op(struct acpi_walk_state *walk_state, }
if (status == AE_CTRL_TERMINATE) { - status = AE_OK; - - /* Clean up */ - do { - if (op) { - status2 = - acpi_ps_complete_this_op - (walk_state, op); - if (ACPI_FAILURE - (status2)) { - return_ACPI_STATUS - (status2); - } - } - - acpi_ps_pop_scope(& - (walk_state-> - parser_state), - &op, - &walk_state-> - arg_types, - &walk_state-> - arg_count); - - } while (op); - - return_ACPI_STATUS(status); + ascending = FALSE; + return_status = AE_CTRL_TERMINATE; }
else if (ACPI_FAILURE(status)) {
/* First error is most important */
- (void) - acpi_ps_complete_this_op(walk_state, - op); - return_ACPI_STATUS(status); + ascending = FALSE; + return_status = status; } }
- status2 = acpi_ps_complete_this_op(walk_state, op); - if (ACPI_FAILURE(status2)) { - return_ACPI_STATUS(status2); + status = acpi_ps_complete_this_op(walk_state, op); + if (ACPI_FAILURE(status)) { + ascending = FALSE; + if (ACPI_SUCCESS(return_status) || + return_status == AE_CTRL_TERMINATE) { + return_status = status; + } } }
@@ -724,5 +703,5 @@ acpi_ps_complete_final_op(struct acpi_walk_state *walk_state,
} while (op);
- return_ACPI_STATUS(status); + return_ACPI_STATUS(return_status); }
From: Qu Wenruo wqu@suse.com
mainline inclusion from mainline commit e4571b8c5e9ffa1e85c0c671995bd4dcc5c75091 bugzilla: 181007 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-3739
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
[BUG] It's easy to trigger NULL pointer dereference, just by removing a non-existing device id:
# mkfs.btrfs -f -m single -d single /dev/test/scratch1 \ /dev/test/scratch2 # mount /dev/test/scratch1 /mnt/btrfs # btrfs device remove 3 /mnt/btrfs
Then we have the following kernel NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 649 Comm: btrfs Not tainted 5.14.0-rc3-custom+ #35 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:btrfs_rm_device+0x4de/0x6b0 [btrfs] btrfs_ioctl+0x18bb/0x3190 [btrfs] ? lock_is_held_type+0xa5/0x120 ? find_held_lock.constprop.0+0x2b/0x80 ? do_user_addr_fault+0x201/0x6a0 ? lock_release+0xd2/0x2d0 ? __x64_sys_ioctl+0x83/0xb0 __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae
[CAUSE] Commit a27a94c2b0c7 ("btrfs: Make btrfs_find_device_by_devspec return btrfs_device directly") moves the "missing" device path check into btrfs_rm_device().
But btrfs_rm_device() itself can have case where it only receives @devid, with NULL as @device_path.
In that case, calling strcmp() on NULL will trigger the NULL pointer dereference.
Before that commit, we handle the "missing" case inside btrfs_find_device_by_devspec(), which will not check @device_path at all if @devid is provided, thus no way to trigger the bug.
[FIX] Before calling strcmp(), also make sure @device_path is not NULL.
Fixes: a27a94c2b0c7 ("btrfs: Make btrfs_find_device_by_devspec return btrfs_device directly") CC: stable@vger.kernel.org # 5.4+ Reported-by: butt3rflyh4ck butterflyhuangxx@gmail.com Reviewed-by: Anand Jain anand.jain@oracle.com Signed-off-by: Qu Wenruo wqu@suse.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Xiu Jianfeng xiujianfeng@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- fs/btrfs/volumes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 920c84fae710..d1fccddcf403 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -2059,7 +2059,7 @@ int btrfs_rm_device(struct btrfs_fs_info *fs_info, const char *device_path,
if (IS_ERR(device)) { if (PTR_ERR(device) == -ENOENT && - strcmp(device_path, "missing") == 0) + device_path && strcmp(device_path, "missing") == 0) ret = BTRFS_ERROR_DEV_MISSING_NOT_FOUND; else ret = PTR_ERR(device);
From: Xiaolong Huang butterflyhuangxx@gmail.com
mainline inclusion from mainline-5.14 commit 7e78c597c3ebfd0cb329aa09a838734147e4f117 bugzilla: 180972 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-3743
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
This check was incomplete, did not consider size is 0:
if (len != ALIGN(size, 4) + hdrlen) goto err;
if size from qrtr_hdr is 0, the result of ALIGN(size, 4) will be 0, In case of len == hdrlen and size == 0 in header this check won't fail and
if (cb->type == QRTR_TYPE_NEW_SERVER) { /* Remote node endpoint can bridge other distant nodes */ const struct qrtr_ctrl_pkt *pkt = data + hdrlen;
qrtr_node_assign(node, le32_to_cpu(pkt->server.node)); }
will also read out of bound from data, which is hdrlen allocated block.
Fixes: 194ccc88297a ("net: qrtr: Support decoding incoming v2 packets") Fixes: ad9d24c9429e ("net: qrtr: fix OOB Read in qrtr_endpoint_post") Signed-off-by: Xiaolong Huang butterflyhuangxx@gmail.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Xiu Jianfeng xiujianfeng@huawei.com Reviewed-by: yuehaibing 00384118 yuehaibing@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- net/qrtr/qrtr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c index 6826558483f9..56cffbfa000b 100644 --- a/net/qrtr/qrtr.c +++ b/net/qrtr/qrtr.c @@ -486,7 +486,7 @@ int qrtr_endpoint_post(struct qrtr_endpoint *ep, const void *data, size_t len) goto err; }
- if (len != ALIGN(size, 4) + hdrlen) + if (!size || len != ALIGN(size, 4) + hdrlen) goto err;
if (cb->dst_port != QRTR_PORT_CTRL && cb->type != QRTR_TYPE_DATA &&
From: Linus Torvalds torvalds@linux-foundation.org
mainline inclusion from mainline commit 2287a51ba822384834dafc1c798453375d1107c7 bugzilla: 181008 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-3753
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
As per the long-suffering comment.
Reported-by: Minh Yuan yuanmingbuaa@gmail.com Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: Jiri Slaby jirislaby@kernel.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Xiu Jianfeng xiujianfeng@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- drivers/tty/vt/vt_ioctl.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c index 09b8d02acd99..90e4fcd3dc39 100644 --- a/drivers/tty/vt/vt_ioctl.c +++ b/drivers/tty/vt/vt_ioctl.c @@ -246,6 +246,8 @@ int vt_waitactive(int n) * * XXX It should at least call into the driver, fbdev's definitely need to * restore their engine state. --BenH + * + * Called with the console lock held. */ static int vt_kdsetmode(struct vc_data *vc, unsigned long mode) { @@ -262,7 +264,6 @@ static int vt_kdsetmode(struct vc_data *vc, unsigned long mode) return -EINVAL; }
- /* FIXME: this needs the console lock extending */ if (vc->vc_mode == mode) return 0;
@@ -271,12 +272,10 @@ static int vt_kdsetmode(struct vc_data *vc, unsigned long mode) return 0;
/* explicitly blank/unblank the screen if switching modes */ - console_lock(); if (mode == KD_TEXT) do_unblank_screen(1); else do_blank_screen(1); - console_unlock();
return 0; } @@ -378,7 +377,10 @@ static int vt_k_ioctl(struct tty_struct *tty, unsigned int cmd, if (!perm) return -EPERM;
- return vt_kdsetmode(vc, arg); + console_lock(); + ret = vt_kdsetmode(vc, arg); + console_unlock(); + return ret;
case KDGETMODE: return put_user(vc->vc_mode, (int __user *)arg);
From: Vasily Averin vvs@virtuozzo.com
mainline inclusion from mainline commit 18319498fdd4cdf8c1c2c48cd432863b1f915d6f bugzilla: 181329 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-3759
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
When user creates IPC objects it forces kernel to allocate memory for these long-living objects.
It makes sense to account them to restrict the host's memory consumption from inside the memcg-limited container.
This patch enables accounting for IPC shared memory segments, messages semaphores and semaphore's undo lists.
Link: https://lkml.kernel.org/r/d6507b06-4df6-78f8-6c54-3ae86e3b5339@virtuozzo.com Signed-off-by: Vasily Averin vvs@virtuozzo.com Reviewed-by: Shakeel Butt shakeelb@google.com Cc: Alexander Viro viro@zeniv.linux.org.uk Cc: Alexey Dobriyan adobriyan@gmail.com Cc: Andrei Vagin avagin@gmail.com Cc: Borislav Petkov bp@alien8.de Cc: Borislav Petkov bp@suse.de Cc: Christian Brauner christian.brauner@ubuntu.com Cc: Dmitry Safonov 0x7f454c46@gmail.com Cc: "Eric W. Biederman" ebiederm@xmission.com Cc: Greg Kroah-Hartman gregkh@linuxfoundation.org Cc: "H. Peter Anvin" hpa@zytor.com Cc: Ingo Molnar mingo@redhat.com Cc: "J. Bruce Fields" bfields@fieldses.org Cc: Jeff Layton jlayton@kernel.org Cc: Jens Axboe axboe@kernel.dk Cc: Jiri Slaby jirislaby@kernel.org Cc: Johannes Weiner hannes@cmpxchg.org Cc: Kirill Tkhai ktkhai@virtuozzo.com Cc: Michal Hocko mhocko@kernel.org Cc: Oleg Nesterov oleg@redhat.com Cc: Roman Gushchin guro@fb.com Cc: Serge Hallyn serge@hallyn.com Cc: Tejun Heo tj@kernel.org Cc: Thomas Gleixner tglx@linutronix.de Cc: Vladimir Davydov vdavydov.dev@gmail.com Cc: Yutian Yang nglaive@gmail.com Cc: Zefan Li lizefan.x@bytedance.com Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Chen Jun chenjun102@huawei.com
Conflicts: ipc/msg.c ipc/sem.c ipc/shm.c Reviewed-by: Wang Hui john.wanghui@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- ipc/msg.c | 2 +- ipc/sem.c | 9 +++++---- ipc/shm.c | 2 +- 3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c index 6e6c8e0c9380..8ded6b8f10a2 100644 --- a/ipc/msg.c +++ b/ipc/msg.c @@ -147,7 +147,7 @@ static int newque(struct ipc_namespace *ns, struct ipc_params *params) key_t key = params->key; int msgflg = params->flg;
- msq = kvmalloc(sizeof(*msq), GFP_KERNEL); + msq = kvmalloc(sizeof(*msq), GFP_KERNEL_ACCOUNT); if (unlikely(!msq)) return -ENOMEM;
diff --git a/ipc/sem.c b/ipc/sem.c index 7d9c06b0ad6e..d3b9b73cd9ca 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -511,7 +511,7 @@ static struct sem_array *sem_alloc(size_t nsems) if (nsems > (INT_MAX - sizeof(*sma)) / sizeof(sma->sems[0])) return NULL;
- sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL); + sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL_ACCOUNT); if (unlikely(!sma)) return NULL;
@@ -1852,7 +1852,7 @@ static inline int get_undo_list(struct sem_undo_list **undo_listp)
undo_list = current->sysvsem.undo_list; if (!undo_list) { - undo_list = kzalloc(sizeof(*undo_list), GFP_KERNEL); + undo_list = kzalloc(sizeof(*undo_list), GFP_KERNEL_ACCOUNT); if (undo_list == NULL) return -ENOMEM; spin_lock_init(&undo_list->lock); @@ -1937,7 +1937,7 @@ static struct sem_undo *find_alloc_undo(struct ipc_namespace *ns, int semid) rcu_read_unlock();
/* step 2: allocate new undo structure */ - new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL); + new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL_ACCOUNT); if (!new) { ipc_rcu_putref(&sma->sem_perm, sem_rcu_free); return ERR_PTR(-ENOMEM); @@ -2001,7 +2001,8 @@ static long do_semtimedop(int semid, struct sembuf __user *tsops, if (nsops > ns->sc_semopm) return -E2BIG; if (nsops > SEMOPM_FAST) { - sops = kvmalloc_array(nsops, sizeof(*sops), GFP_KERNEL); + sops = kvmalloc_array(nsops, sizeof(*sops), + GFP_KERNEL_ACCOUNT); if (sops == NULL) return -ENOMEM; } diff --git a/ipc/shm.c b/ipc/shm.c index e25c7c6106bc..fce0b7b12939 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -619,7 +619,7 @@ static int newseg(struct ipc_namespace *ns, struct ipc_params *params) ns->shm_tot + numpages > ns->shm_ctlall) return -ENOSPC;
- shp = kvmalloc(sizeof(*shp), GFP_KERNEL); + shp = kvmalloc(sizeof(*shp), GFP_KERNEL_ACCOUNT); if (unlikely(!shp)) return -ENOMEM;
From: Theodore Ts'o tytso@mit.edu
mainline inclusion from mainline commit a54c4613dac1500b40e4ab55199f7c51f028e848 bugzilla: 181006 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-40490
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
--------------------------------
The location of the system.data extended attribute can change whenever xattr_sem is not taken. So we need to recalculate the i_inline_off field since it mgiht have changed between ext4_write_begin() and ext4_write_end().
This means that caching i_inline_off is probably not helpful, so in the long run we should probably get rid of it and shrink the in-memory ext4 inode slightly, but let's fix the race the simple way for now.
Cc: stable@kernel.org Fixes: f19d5870cbf72 ("ext4: add normal write support for inline data") Reported-by: syzbot+13146364637c7363a7de@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o tytso@mit.edu Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Xiu Jianfeng xiujianfeng@huawei.com Reviewed-by: Zhang Yi yi.zhang@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- fs/ext4/inline.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c index b41512d1badc..0f7b53d5edea 100644 --- a/fs/ext4/inline.c +++ b/fs/ext4/inline.c @@ -750,6 +750,12 @@ int ext4_write_inline_data_end(struct inode *inode, loff_t pos, unsigned len, ext4_write_lock_xattr(inode, &no_expand); BUG_ON(!ext4_has_inline_data(inode));
+ /* + * ei->i_inline_off may have changed since ext4_write_begin() + * called ext4_try_to_write_inline_data() + */ + (void) ext4_find_inline_data_nolock(inode); + kaddr = kmap_atomic(page); ext4_write_inline_data(inode, &iloc, kaddr, pos, len); kunmap_atomic(kaddr);
From: Jens Axboe axboe@kernel.dk
stable inclusion from stable-5.10.68 commit ce8f81b76d3bef7b9fe6c8f84d029ab898b19469 bugzilla: 182253 https://gitee.com/openeuler/kernel/issues/I4DDEL CVE: CVE-2021-41073
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...
--------------------------------
commit 16c8d2df7ec0eed31b7d3b61cb13206a7fb930cc upstream.
When setting up the next segment, we check what type the iter is and handle it accordingly. However, when incrementing and processed amount we do not, and both iter advance and addr/len are adjusted, regardless of type. Split the increment side just like we do on the setup side.
Fixes: 4017eb91a9e7 ("io_uring: make loop_rw_iter() use original user supplied pointers") Cc: stable@vger.kernel.org Reported-by: Valentina Palmiotti vpalmiotti@gmail.com Reviewed-by: Pavel Begunkov asml.silence@gmail.com Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Chen Jun chenjun102@huawei.com Reviewed-by: Yang Erkun yangerkun@huawei.com Signed-off-by: Chen Jun chenjun102@huawei.com --- fs/io_uring.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c index 108b0ed31c11..4361ed15e019 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -3203,12 +3203,15 @@ static ssize_t loop_rw_iter(int rw, struct io_kiocb *req, struct iov_iter *iter) ret = nr; break; } + if (!iov_iter_is_bvec(iter)) { + iov_iter_advance(iter, nr); + } else { + req->rw.len -= nr; + req->rw.addr += nr; + } ret += nr; if (nr != iovec.iov_len) break; - req->rw.len -= nr; - req->rw.addr += nr; - iov_iter_advance(iter, nr); }
return ret;