Commits · 42268ea1959cc4dcd43d31778d8199b0b6a1c62a · Summer2022 / 22b970497

Aug 19, 2022

x86/speculation: Add RSB VM Exit protections · 42268ea1

Daniel Sneddon authored 2 years ago

stable inclusion
from stable-v4.19.255
commit b6c5011934a15762cd694e36fe74f2f2f93eac9b
category: bugfix
bugzilla: 187492, https://gitee.com/src-openeuler/kernel/issues/I5N1SO
CVE: CVE-2022-26373

--------------------------------

commit 2b1299322016731d56807aa49254a5ea3080b6b3 upstream.

tl;dr: The Enhanced IBRS mitigation for Spectre v2 does not work as
documented for RET instructions after VM exits. Mitigate it with a new
one-entry RSB stuffing mechanism and a new LFENCE.

== Background ==

Indirect Branch Restricted Speculation (IBRS) was designed to help
mitigate Branch Target Injection and Speculative Store Bypass, i.e.
Spectre, attacks. IBRS prevents software run in less privileged modes
from affecting branch prediction in more privileged modes. IBRS requires
the MSR to be written on every privilege level change.

To overcome some of the performance issues of IBRS, Enhanced IBRS was
introduced.  eIBRS is an "always on" IBRS, in other words, just turn
it o...

42268ea1

Aug 18, 2022

Revert "blk-mq: fix null pointer dereference in blk_mq_queue_tag_busy_ite" · 7326996c

Li Nan authored 2 years ago

hulk inclusion
category: bugfix
bugzilla: 187497, https://gitee.com/openeuler/kernel/issues/I5MT95


CVE: NA

--------------------------------

This reverts commit 64ba823f.

Commit fea9f92f1748 introduce the bug. It is a patch for performance
optimization and this version doesn't have to backport it.
blk_mq_queue_tag_busy_iter() won't access q->tag_set->flags or reference
other fields in q that is uninitialized at present. 64ba823f will
make io hang for special scsi drivers(e.x. ata_piix). Revert it.

Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

7326996c

Aug 16, 2022

blk-mq: fix null pointer dereference in blk_mq_queue_tag_busy_ite · b8b1d321

Li Nan authored 2 years ago

hulk inclusion
category: bugfix
bugzilla: 187489, https://gitee.com/openeuler/kernel/issues/I5MKPP


CVE: NA

--------------------------------

The q->tag_set can be NULL in blk_mq_queue_tag_busy_ite() while queue
has not been initialized:

	CPU0					CPU1
dm_mq_init_request_queue
  md->tag_set = kzalloc_node
    blk_mq_init_allocated_queue
      q->mq_ops = set->ops;
					diskstats_show
					  part_get_stat_info
					    if(q->mq_ops)
					      blk_mq_in_flight_with_stat
						blk_mq_queue_tag_busy_ite
						  if (blk_mq_is_shared_tags(q->tag_set->flags))
						  //q->tag_set is null here
      q->tag_set = set
blk_register_queue
  blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q)

There is same bug when cat /sys/block/[device]/inflight. Fix it by checking
the flag 'QUEUE_FLAG_REGISTERED'. Althrough this may cause some io not to
be counted temporarily, it doesn't hurt in real user case.

Signed-off-by: Li Nan <linan122@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

b8b1d321

arm64: Avoid premature usercopy failure for __arch_copy_to_user_generic_read · 3e4202a6

童甜根 authored 2 years ago

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MJU8


CVE: NA

---------------------------------

Commit 1b1b4ded ("arm64: Avoid premature usercopy failure") fixes an
usercopy failure issues, it introduced a variable srcin and used it in
fixup routine, but the variable is not initialized in
__arch_copy_to_user_generic_read(), this will cause an illegal pointer
issue in fixup.

Fixes: 1b1b4ded ("arm64: Avoid premature usercopy failure")
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Tested-by: yongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

3e4202a6

net_sched: cls_route: remove from list when handle is 0 · a3ef422a

Thadeu Lima de Souza Cascardo authored 2 years ago

mainline inclusion
from mainline-v6.0-rc1
commit 9ad36309e2719a884f946678e0296be10f0bb4c1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5LJLR


CVE: CVE-2022-2588

--------------------------------

When a route filter is replaced and the old filter has a 0 handle, the old
one won't be removed from the hashtable, while it will still be freed.

The test was there since before commit 1109c005 ("net: sched: RCU
cls_route"), when a new filter was not allocated when there was an old one.
The old filter was reused and the reinserting would only be necessary if an
old filter was replaced. That was still wrong for the same case where the
old handle was 0.

Remove the old filter from the list independently from its handle value.

This fixes CVE-2022-2588, also reported as ZDI-CAN-17440.

Reported-by: Zhenpeng Lin <zplin@u.northwestern.edu>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Reviewed-by: Kamal Mostafa <kamal@canonical.com>
Cc: <stable@vger.kernel.org>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://lore.kernel.org/r/20220809170518.164662-1-cascardo@canonical.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Xu Jia <xujia39@huawei.com>
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Wang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

a3ef422a

Aug 15, 2022

Revert "x86/unwind/orc: Change REG_SP_INDIRECT" · 98090d64

Yipeng Zou authored 2 years ago

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5MC71


CVE: NA

---------------------------------

This reverts commit 657a6bec.

This patch was backport from mainline and intend to fix REG_SP_INDIRECT
type in orc unwinder.The patch was fix an objtools problem on mainline,
which The upstream commit havn't been merged in hulk-4.19,and it led to
parse the sp value form orc data was wrong. So we need revert this patch.

Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

4.19.90-2208.4.0

98090d64

Phytium/S2500: kdump: Avoid vmcore saving failure across multi-socket · 1db3436e

Zheng Zengkai authored 2 years ago

phytium inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I41AUQ



--------------------------------------

On phytium S2500 multi-socket server, for example 2-socket(2P), there are
socekt0 and socket1 on the server:
If storage device(like SAS controller and disks to save vmcore into) is
installed on socket1 and second kernel brings up 2 CPUs both on socket0 with
nr_cpus=2, then vmcore will fail to be saved into the disk as interrupts like
SPI and LPI(except SGI) can't communicate across cpu sockets in this server
platform.

To avoid this issue, Bypass other non-cpu0 to ensure that each cpu0 on each
socket can boot up and handle interrupt when booting the second kernel.

Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin@huawei.com>

1db3436e

PCI: Add config control for phytium ACS quirks · 35380d1e

Zheng Zengkai authored 2 years ago

phytium inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I41AUQ



--------------------------------------

Use CONFIG_ARCH_PHYTIUM to control phytium ACS quirks.

Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Laibin Qiu <qiulaibin@huawei.com>

35380d1e

scsi: libiscsi: Teardown iscsi_cls_conn gracefully · 6691e5cb

Wenchao Hao authored 2 years ago

mainline inclusion
from mainline-v5.18-rc1
commit 8709c323091be019f76a49cf783052a5636aca85
category: bugfix
bugzilla: 187381, https://gitee.com/openeuler/kernel/issues/I5LBFL
CVE: NA

--------------------------------

Commit 1b8d0300a3e9 ("scsi: libiscsi: Fix UAF in
iscsi_conn_get_param()/iscsi_conn_teardown()") fixed an UAF in
iscsi_conn_get_param() and introduced 2 tmp_xxx varibles.

We can gracefully fix this UAF with the help of device_del(). Calling
iscsi_remove_conn() at the beginning of iscsi_conn_teardown would make
userspace unable to see iscsi_cls_conn. This way we we can free memory
safely.

Remove iscsi_destroy_conn() since it is no longer used.

Link: https://lore.kernel.org/r/20220310015759.3296841-4-haowenchao@huawei.com


Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
Signed-off-by: Wu Bo <wubo40@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Conflict: ...

6691e5cb

scsi: libiscsi: Add iscsi_cls_conn to sysfs after initialization · a9852947

Wenchao Hao authored 2 years ago

mainline inclusion
from mainline-v5.18-rc1
commit 7dae459f5e56a89ab01413ae055595c982713349
category: bugfix
bugzilla: 187381, https://gitee.com/openeuler/kernel/issues/I5LBFL
CVE: NA

--------------------------------

iscsi_create_conn() exposed iscsi_cls_conn to sysfs prior to initialization
of iscsi_conn's dd_data. When userspace tried to access an attribute such
as the connect address, a NULL pointer dereference was observed.

Do not add iscsi_cls_conn to sysfs until it has been initialized.  Remove
iscsi_create_conn() since it is no longer used.

Link: https://lore.kernel.org/r/20220310015759.3296841-3-haowenchao@huawei.com


Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
Signed-off-by: Wu Bo <wubo40@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Conflict: iscsi_create_conn() is not removed
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

a9852947

scsi: iscsi: Add helper functions to manage iscsi_cls_conn · 3a9a65bd

Wenchao Hao authored 2 years ago

mainline inclusion
from mainline-v5.18-rc1
commit ad515cada7dac3cdf5e1ad77a0ed696f5f34e0ab
category: bugfix
bugzilla: 187381, https://gitee.com/openeuler/kernel/issues/I5LBFL
CVE: NA

--------------------------------

 - iscsi_alloc_conn(): Allocate and initialize iscsi_cls_conn

 - iscsi_add_conn(): Expose iscsi_cls_conn to userspace via sysfs

 - iscsi_remove_conn(): Remove iscsi_cls_conn from sysfs

Link: https://lore.kernel.org/r/20220310015759.3296841-2-haowenchao@huawei.com


Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Wenchao Hao <haowenchao@huawei.com>
Signed-off-by: Wu Bo <wubo40@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

Conflict: drivers/scsi/scsi_transport_iscsi.c
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

3a9a65bd

media: v4l2-mem2mem: Apply DST_QUEUE_OFF_BASE on MMAP buffers across ioctls · b2176cb0

Chen-Yu Tsai authored 2 years ago

stable inclusion
from stable-v5.10.110
commit 8a83731a09a5954b85b1ce49c01ff5c2a3465cb7
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5KKB1


CVE: CVE-2022-20369

--------------------------------

[ Upstream commit 8310ca94075e784bbb06593cd6c068ee6b6e4ca6 ]

DST_QUEUE_OFF_BASE is applied to offset/mem_offset on MMAP capture buffers
only for the VIDIOC_QUERYBUF ioctl, while the userspace fields (including
offset/mem_offset) are filled in for VIDIOC_{QUERY,PREPARE,Q,DQ}BUF
ioctls. This leads to differences in the values presented to userspace.
If userspace attempts to mmap the capture buffer directly using values
from DQBUF, it will fail.

Move the code that applies the magic offset into a helper, and call
that helper from all four ioctl entry points.

[hverkuil: drop unnecessary '= 0' in v4l2_m2m_querybuf() for ret]

Fixes: 7f98639d ("V4L/DVB: add memory-to-memory device helper framework for videobuf")
Fixes: 908a0d7c ("[media] v4l: mem2mem: port to videobuf2")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Chen Jun <chenjun102@huawei.com>
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Reviewed-by: Zhang Qiao <zhangqiao22@huawei.com>
Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

b2176cb0

sched: Fix null-ptr-deref in free_fair_sched_group · 0d2df28e

Hui Tang authored 2 years ago

hulk inclusion
category: bugfix
bugzilla: 187419, https://gitee.com/openeuler/kernel/issues/I5LIPL


CVE: NA

-------------------------------

do_el0_svc+0x50/0x11c arch/arm64/kernel/syscall.c:217
 el0_svc+0x20/0x30 arch/arm64/kernel/entry-common.c:353
 el0_sync_handler+0xe4/0x1e0 arch/arm64/kernel/entry-common.c:369
 el0_sync+0x148/0x180 arch/arm64/kernel/entry.S:683

==================================================================
BUG: KASAN: null-ptr-deref in rq_of kernel/sched/sched.h:1118 [inline]
BUG: KASAN: null-ptr-deref in unthrottle_qos_sched_group kernel/sched/fair.c:7619 [inline]
BUG: KASAN: null-ptr-deref in free_fair_sched_group+0x124/0x320 kernel/sched/fair.c:12131
Read of size 8 at addr 0000000000000130 by task syz-executor100/223

CPU: 3 PID: 223 Comm: syz-executor100 Not tainted 5.10.0 #6
Hardware name: linux,dummy-virt (DT)
Call trace:
 dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132
 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b4/0x248 lib/dump_stack.c:118
 __kasan_report mm/kasan/report.c:551 [inline]
 kasan_report+0x18c/0x210 mm/kasan/report.c:564
 check_memory_region_inline mm/kasan/generic.c:187 [inline]
 __asan_load8+0x98/0xc0 mm/kasan/generic.c:253
 rq_of kernel/sched/sched.h:1118 [inline]
 unthrottle_qos_sched_group kernel/sched/fair.c:7619 [inline]
 free_fair_sched_group+0x124/0x320 kernel/sched/fair.c:12131
 sched_free_group kernel/sched/core.c:7767 [inline]
 sched_create_group+0x48/0xc0 kernel/sched/core.c:7798
 cpu_cgroup_css_alloc+0x18/0x40 kernel/sched/core.c:7930
 css_create+0x7c/0x4a0 kernel/cgroup/cgroup.c:5328
 cgroup_apply_control_enable+0x288/0x340 kernel/cgroup/cgroup.c:3135
 cgroup_apply_control kernel/cgroup/cgroup.c:3217 [inline]
 cgroup_subtree_control_write+0x668/0x8b0 kernel/cgroup/cgroup.c:3375
 cgroup_file_write+0x1a8/0x37c kernel/cgroup/cgroup.c:3909
 kernfs_fop_write_iter+0x220/0x2f4 fs/kernfs/file.c:296
 call_write_iter include/linux/fs.h:1960 [inline]
 new_sync_write+0x260/0x370 fs/read_write.c:515
 vfs_write+0x3dc/0x4ac fs/read_write.c:602
 ksys_write+0xfc/0x200 fs/read_write.c:655
 __do_sys_write fs/read_write.c:667 [inline]
 __se_sys_write fs/read_write.c:664 [inline]
 __arm64_sys_write+0x50/0x60 fs/read_write.c:664
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
 el0_svc_common.constprop.0+0xf4/0x414 arch/arm64/kernel/syscall.c:155
 do_el0_svc+0x50/0x11c arch/arm64/kernel/syscall.c:217
 el0_svc+0x20/0x30 arch/arm64/kernel/entry-common.c:353
 el0_sync_handler+0xe4/0x1e0 arch/arm64/kernel/entry-common.c:369
 el0_sync+0x148/0x180 arch/arm64/kernel/entry.S:683

So add check for tg->cfs_rq[i] before unthrottle_qos_sched_group() called.

Signed-off-by: Hui Tang <tanghui20@huawei.com>
Reviewed-by: Zhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

0d2df28e

Aug 12, 2022

RDMA/ib_srp: Fix a deadlock · b363c74b

Bart Van Assche authored 2 years ago

stable inclusion
from stable-4.19.232
commit d7997d19dfa7001ca41e971cd9efd091bb195b51
category: bugfix
https: https://gitee.com/openeuler/kernel/issues/I5LYLQ
CVE: NA

--------------------------------

[ Upstream commit 081bdc9fe05bb23248f5effb6f811da3da4b8252 ]

Remove the flush_workqueue(system_long_wq) call since flushing
system_long_wq is deadlock-prone and since that call is redundant with a
preceding cancel_work_sync()

Link: https://lore.kernel.org/r/20220215210511.28303-3-bvanassche@acm.org


Fixes: ef6c49d8 ("IB/srp: Eliminate state SRP_TARGET_DEAD")
Reported-by:  <syzbot+831661966588c802aae9@syzkaller.appspotmail.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Luo Meng <luomeng12@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

b363c74b

mm/slub: add missing TID updates on slab deactivation · d1ac93cf

Jann Horn authored 2 years ago

stable inclusion
from stable-4.19.252
commit e2b2f0e2e34d71ae6c2a1114fd3c525930e84bc7
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5LJH1
CVE: NA

--------------------------------

commit eeaa345e128515135ccb864c04482180c08e3259 upstream.

The fastpath in slab_alloc_node() assumes that c->slab is stable as long as
the TID stays the same. However, two places in __slab_alloc() currently
don't update the TID when deactivating the CPU slab.

If multiple operations race the right way, this could lead to an object
getting lost; or, in an even more unlikely situation, it could even lead to
an object being freed onto the wrong slab's freelist, messing up the
`inuse` counter and eventually causing a page to be freed to the page
allocator while it still contains slab objects.

(I haven't actually tested these cases though, this is just based on
looking at the code. Writing testcases for this stuff seems like it'd be
a pain...)

The race l...

d1ac93cf

Aug 09, 2022

block: fix regression for dm · b9484a85

余快 authored 2 years ago

hulk inclusion
category: bugfix
bugzilla: 187345, https://gitee.com/openeuler/kernel/issues/I5KZZ0


CVE: NA

--------------------------------

Commit faf2662e ("block: fix that part scan is disabled in
device_add_disk()") introduce a regression:

Test procedures:
dmsetup create test --notable
dmsetup remove test

Test result:
dmsetup will stuck forever

Root cause:
before:
1) dmsetup creat
    add_disk_add_disk_no_queue_reg()
     scan partitions
     uevent
2) blk_register_queue -> notable will not call this
3) dmsetup remove
    wait for uevent

after:
1) dmsetup creat
    add_disk_add_disk_no_queue_reg()
2) blk_register_queue() -> notable will not call this
    scan_partitions
    uevent
3) dmsetup remove
    wait for uevent -> impossible for notable

Fix the problem by moving scan_partitions and uevent from
blk_register_queue() to the end of add_disk_add_disk_no_queue_reg().

Fixes: faf2662e ("block: fix that part scan is disabled in device_add_disk()")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

4.19.90-2208.3.0

b9484a85

blk-mq: handle bio after queue is initialized · 4ee1fb09

余快 authored 2 years ago

hulk inclusion
category: bugfix
bugzilla: 187345, https://gitee.com/openeuler/kernel/issues/I5KZZ0


CVE: NA

--------------------------------

Otherwise, null pointer crash can be triggered to handle bio in
blk_mq_submit_bio() while queue is not initialized.

Since queue is registered right after initialization, use the flag
'QUEUE_FLAG_REGISTERED' to make sure queue is initialized, althrough
this will delay a little when bio can be handled, it doesn't hurt in
real user case.

Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

4ee1fb09

x86: Clear .brk area at early boot · a11882b6

Juergen Gross authored 2 years ago

stable inclusion
from stable-4.19.253
commit 36e2f161fb01795722f2ff1a24d95f08100333dd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5JTYM


CVE: CVE-2022-36123

--------------------------------

[ Upstream commit 38fa5479b41376dc9d7f57e71c83514285a25ca0 ]

The .brk section has the same properties as .bss: it is an alloc-only
section and should be cleared before being used.

Not doing so is especially a problem for Xen PV guests, as the
hypervisor will validate page tables (check for writable page tables
and hypervisor private bits) before accepting them to be used.

Make sure .brk is initially zero by letting clear_bss() clear the brk
area, too.

Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20220630071441.28576-3-jgross@suse.com


Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

a11882b6

signal/seccomp: Dump core when there is only one live thread · b9fe1379

Eric W. Biederman authored 2 years ago

mainline inclusion
from mainline-v5.15-rc1
commit d21918e5a94a862ccb297b9f2be38574c865fda0
category: bugfix
bugzilla: 187336, https://gitee.com/openeuler/kernel/issues/I5LCBR


CVE: NA

--------------------------------

Replace get_nr_threads with atomic_read(&current->signal->live) as
that is a more accurate number that is decremented sooner.

Acked-by: Kees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/87lf6z6qbd.fsf_-_@disp2133


Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

Conflicts:
	kernel/seccomp.c

Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: Wang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

b9fe1379

x86/unwind/orc: Recheck address range after stack info was updated · f12cb796

Dmitry Monakhov authored 2 years ago

mainline inclusion
from mainline-v5.18-rc5
commit 6c8ef58a50b5fab6e364b558143490a2014e2a4f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5LCHG


CVE: NA

--------------------------------

A crash was observed in the ORC unwinder:

  BUG: stack guard page was hit at 000000000dd984a2 (stack is 00000000d1caafca..00000000613712f0)
  kernel stack overflow (page fault): 0000 [#1] SMP NOPTI
  CPU: 93 PID: 23787 Comm: context_switch1 Not tainted 5.4.145 #1
  RIP: 0010:unwind_next_frame
  Call Trace:
   <NMI>
   perf_callchain_kernel
   get_perf_callchain
   perf_callchain
   perf_prepare_sample
   perf_event_output_forward
   __perf_event_overflow
   perf_ibs_handle_irq
   perf_ibs_nmi_handler
   nmi_handle
   default_do_nmi
   do_nmi
   end_repeat_nmi

This was really two bugs:

  1) The perf IBS code passed inconsistent regs to the unwinder.

  2) The unwinder didn't handle the bad input gracefully.

Fix the latter bug.  The ORC unwinder needs to be immune against bad
inputs.  The problem is that stack_access_ok() doesn't recheck the
validity of the full range of registers after switching to the next
valid stack with get_stack_info().  Fix that.

[ jpoimboe: rewrote commit log ]

Signed-off-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lore.kernel.org/r/1650353656-956624-1-git-send-email-dmtrmonakhov@yandex-team.ru


Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Reviewed-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

f12cb796

x86/unwind/orc: Silence warnings caused by missing ORC data · 584263f3

Josh Poimboeuf authored 2 years ago

mainline inclusion
from mainline-v5.12-rc3
commit b59cc97674c947861783ca92b9a6e7d043adba96
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5LCHG


CVE: NA

--------------------------------

The ORC unwinder attempts to fall back to frame pointers when ORC data
is missing for a given instruction.  It sets state->error, but then
tries to keep going as a best-effort type of thing.  That may result in
further warnings if the unwinder gets lost.

Until we have some way to register generated code with the unwinder,
missing ORC will be expected, and occasionally going off the rails will
also be expected.  So don't warn about it.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Ivan Babrou <ivan@cloudflare.com>
Link: https://lkml.kernel.org/r/06d02c4bbb220bd31668db579278b0352538efbb.1612534649.git.jpoimboe@redhat.com


Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Reviewed-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

584263f3

x86/unwind/orc: Change REG_SP_INDIRECT · 657a6bec

Peter Zijlstra authored 2 years ago

mainline inclusion
from mainline-v5.12-rc1
commit 87ccc826bf1c9e5ab4c2f649b404e02c63e47622
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5LCHG


CVE: NA

--------------------------------

Currently REG_SP_INDIRECT is unused but means (%rsp + offset),
change it to mean (%rsp) + offset.

The reason is that we're going to swizzle stack in the middle of a C
function with non-trivial stack footprint. This means that when the
unwinder finds the ToS, it needs to dereference it (%rsp) and then add
the offset to the next frame, resulting in: (%rsp) + offset

This is somewhat unfortunate, since REG_BP_INDIRECT is used (by DRAP)
and thus needs to retain the current (%rbp + offset).

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Reviewed-by: Zhang Jianhua <chris.zjh@huawei.com>
Reviewed-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

657a6bec

netfilter: nf_queue: do not allow packet truncation below transport header offset · 800dcea0

Florian Westphal authored 2 years ago

mainline inclusion
from mainline-v5.19-rc3
commit 99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5J9R4


CVE: CVE-2022-36946

--------------------------------

Domingo Dirutigliano and Nicola Guerrera report kernel panic when
sending nf_queue verdict with 1-byte nfta_payload attribute.

The IP/IPv6 stack pulls the IP(v6) header from the packet after the
input hook.

If user truncates the packet below the header size, this skb_pull() will
result in a malformed skb (skb->len < 0).

Fixes: 7af4cc3f ("[NETFILTER]: Add "nfnetlink_queue" netfilter queue handler over nfnetlink")
Reported-by: Domingo Dirutigliano <pwnzer0tt1@proton.me>
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

4.19.90-2208.2.0

800dcea0

Aug 08, 2022

openvswitch: fix OOB access in reserve_sfa_size() · 0947a678

Paolo Valerio authored 2 years ago

stable inclusion
from stable-v4.19.240
commit bbbf059337f9a74285c1cf088ff85ee92d149e64
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5KKF2


CVE: CVE-2022-2639

-------------------------------------------------

commit cefa91b2332d7009bc0be5d951d6cbbf349f90f8 upstream.

Given a sufficiently large number of actions, while copying and
reserving memory for a new action of a new flow, if next_offset is
greater than MAX_ACTIONS_BUFSIZE, the function reserve_sfa_size() does
not return -EMSGSIZE as expected, but it allocates MAX_ACTIONS_BUFSIZE
bytes increasing actions_len by req_size. This can then lead to an OOB
write access, especially when further actions need to be copied.

Fix it by rearranging the flow action size check.

KASAN splat below:

==================================================================
BUG: KASAN: slab-out-of-bounds in reserve_sfa_size+0x1ba/0x380 [openvswitch]
Write of size 65360 at addr ffff888147e4001c by task handler15/836

CPU: 1 PID: 836 Comm: handler15 Not tainted 5.18.0-rc1+ #27
...
Call Trace:
 <TASK>
 dump_stack_lvl+0x45/0x5a
 print_report.cold+0x5e/0x5db
 ? __lock_text_start+0x8/0x8
 ? reserve_sfa_size+0x1ba/0x380 [openvswitch]
 kasan_report+0xb5/0x130
 ? reserve_sfa_size+0x1ba/0x380 [openvswitch]
 kasan_check_range+0xf5/0x1d0
 memcpy+0x39/0x60
 reserve_sfa_size+0x1ba/0x380 [openvswitch]
 __add_action+0x24/0x120 [openvswitch]
 ovs_nla_add_action+0xe/0x20 [openvswitch]
 ovs_ct_copy_action+0x29d/0x1130 [openvswitch]
 ? __kernel_text_address+0xe/0x30
 ? unwind_get_return_address+0x56/0xa0
 ? create_prof_cpu_mask+0x20/0x20
 ? ovs_ct_verify+0xf0/0xf0 [openvswitch]
 ? prep_compound_page+0x198/0x2a0
 ? __kasan_check_byte+0x10/0x40
 ? kasan_unpoison+0x40/0x70
 ? ksize+0x44/0x60
 ? reserve_sfa_size+0x75/0x380 [openvswitch]
 __ovs_nla_copy_actions+0xc26/0x2070 [openvswitch]
 ? __zone_watermark_ok+0x420/0x420
 ? validate_set.constprop.0+0xc90/0xc90 [openvswitch]
 ? __alloc_pages+0x1a9/0x3e0
 ? __alloc_pages_slowpath.constprop.0+0x1da0/0x1da0
 ? unwind_next_frame+0x991/0x1e40
 ? __mod_node_page_state+0x99/0x120
 ? __mod_lruvec_page_state+0x2e3/0x470
 ? __kasan_kmalloc_large+0x90/0xe0
 ovs_nla_copy_actions+0x1b4/0x2c0 [openvswitch]
 ovs_flow_cmd_new+0x3cd/0xb10 [openvswitch]
 ...

Cc: stable@vger.kernel.org
Fixes: f28cd2af ("openvswitch: fix flow actions reallocation")
Signed-off-by: Paolo Valerio <pvalerio@redhat.com>
Acked-by: Eelco Chaudron <echaudro@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lu Wei <luwei32@huawei.com>
Reviewed-by: Yue Haibing <yuehaibing@huawei.com>
Reviewed-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

0947a678

dm thin: use refcount_t for thin_c reference counting · 8719ee2d

John Pittman authored 2 years ago

mainline inclusion
from mainline-v4.20-rc1
commit 22d4c291
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5KSEX


CVE: NA

--------------------------------

The API surrounding refcount_t should be used in place of atomic_t
when variables are being used as reference counters.  It can
potentially prevent reference counter overflows and use-after-free
conditions.  In the dm thin layer, one such example is tc->refcount.
Change this from the atomic_t API to the refcount_t API to prevent
mentioned conditions.

Signed-off-by: John Pittman <jpittman@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Luo Meng <luomeng12@huawei.com>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

8719ee2d

exec: Force single empty string when argv is empty · 72b32d44

Kees Cook authored 2 years ago

stable inclusion
from stable-v4.19.246
commit b50fb8dbc8b81aaa126387de428f4c42a7c72a73
bugzilla: https://gitee.com/openeuler/kernel/issues/I5IGTA
CVE: NA

--------------------------------

exec: Force single empty string when argv is empty

commit dcd46d897adb70d63e025f175a00a89797d31a43 upstream.

Quoting[1] Ariadne Conill:

"In several other operating systems, it is a hard requirement that the
second argument to execve(2) be the name of a program, thus prohibiting
a scenario where argc < 1. POSIX 2017 also recommends this behaviour,
but it is not an explicit requirement[2]:

    The argument arg0 should point to a filename string that is
    associated with the process being started by one of the exec
    functions.
...
Interestingly, Michael Kerrisk opened an issue about this in 2008[3],
but there was no consensus to support fixing this issue then.
Hopefully now that CVE-2021-4034 shows practical exploitative use[4]
of this bug in a shellcode, we can reconsider.

This issue is being tracked in the KSPP issue tracker[5]."

While the initial code searches[6][7] turned up what appeared to be
mostly corner case tests, trying to that just reject argv == NULL
(or an immediately terminated pointer list) quickly started tripping[8]
existing userspace programs.

The next best approach is forcing a single empty string into argv and
adjusting argc to match. The number of programs depending on argc == 0
seems a smaller set than those calling execve with a NULL argv.

Account for the additional stack space in bprm_stack_limits(). Inject an
empty string when argc == 0 (and set argc = 1). Warn about the case so
userspace has some notice about the change:

    process './argc0' launched './argc0' with NULL argv: empty string added

Additionally WARN() and reject NULL argv usage for kernel threads.

[1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
[3] https://bugzilla.kernel.org/show_bug.cgi?id=8408
[4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
[5] https://github.com/KSPP/linux/issues/176
[6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0
[7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0
[8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/



Reported-by: Ariadne Conill <ariadne@dereferenced.org>
Reported-by: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Rich Felker <dalias@libc.org>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: linux-fsdevel@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Christian Brauner <brauner@kernel.org>
Acked-by: Ariadne Conill <ariadne@dereferenced.org>
Acked-by: Andy Lutomirski <luto@kernel.org>
Link: https://lore.kernel.org/r/20220201000947.2453721-1-keescook@chromium.org


[vegard: fixed conflicts due to missing
 886d7de6^- and
 3950e975^- and
 655c16a8]
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zhao Wenhui <zhaowenhui8@huawei.com>
Reviewed-by: zheng zucheng <zhengzucheng@huawei.com>
Reviewed-by: Zhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

72b32d44

usb: gadget: rndis: prevent integer overflow in rndis_set_response() · e323c988

Dan Carpenter authored 2 years ago

mainline inclusion
from mainline-v5.17
commit 65f3324f4b6fed78b8761c3b74615ecf0ffa81fa
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5KBY1


CVE: NA

--------------------------------

If "BufOffset" is very large the "BufOffset + 8" operation can have an
integer overflow.

Cc: stable@kernel.org
Fixes: 38ea1eac7d88 ("usb: gadget: rndis: check size of RNDIS_MSG_SET command")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20220301080424.GA17208@kili


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

e323c988

serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle · 02d2d630

Ilpo Järvinen authored 2 years ago

stable inclusion
from stable-4.19.253
commit c44117bf20a00d377b74f67e36ebe47db1964efd
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

commit 211565b100993c90b53bf40851eacaefc830cfe0 upstream.

The driver must provide throttle and unthrottle in uart_ops when it
sets UPSTAT_AUTORTS. Add them using existing stop_rx &
enable_interrupts functions.

Fixes: 2a76fa28 (serial: pl011: Adopt generic flag to store auto RTS status)
Cc: stable <stable@kernel.org>
Cc: Lukas Wunner <lukas@wunner.de>
Reported-by: Nuno Gonçalves <nunojpg@gmail.com>
Tested-by: Nuno Gonçalves <nunojpg@gmail.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20220614075637.8558-1-ilpo.jarvinen@linux.intel.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

02d2d630

serial: 8250: fix return error code in serial8250_request_std_resource() · a381471c

Yi Yang authored 2 years ago

stable inclusion
from stable-4.19.253
commit 774412bd40594620e9cbca90465eb477c4e3f09e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

commit 6e690d54cfa802f939cefbd2fa2c91bd0b8bd1b6 upstream.

If port->mapbase = NULL in serial8250_request_std_resource() , it need
return a error code instead of 0. If uart_set_info() fail to request new
regions by serial8250_request_std_resource() but the return value of
serial8250_request_std_resource() is 0, The system incorrectly considers
that the resource application is successful and does not attempt to
restore the old setting. A null pointer reference is triggered when the
port resource is later invoked.

Signed-off-by: Yi Yang <yiyang13@huawei.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20220628083515.64138-1-yiyang13@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

a381471c

ipv4: Fix data-races around sysctl_ip_dynaddr. · e05bdf19

Kuniyuki Iwashima authored 2 years ago

stable inclusion
from stable-4.19.253
commit a720ca682386beec7829d1af60cd0f21c6597a01
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

[ Upstream commit e49e4aff7ec19b2d0d0957ee30e93dade57dab9e ]

While reading sysctl_ip_dynaddr, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its readers.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

e05bdf19

icmp: Fix a data-race around sysctl_icmp_ratemask. · 18c37308

Kuniyuki Iwashima authored 2 years ago

stable inclusion
from stable-4.19.253
commit d93993b165243a0f614b946f417fbbb137b34ee2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

[ Upstream commit 1ebcb25ad6fc3d50fca87350acf451b9a66dd31e ]

While reading sysctl_icmp_ratemask, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

18c37308

icmp: Fix a data-race around sysctl_icmp_ratelimit. · d8bcf75f

Kuniyuki Iwashima authored 2 years ago

stable inclusion
from stable-4.19.253
commit 9b07e84b2bcf5e42302070d693e3464fdef9d844
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

[ Upstream commit 2a4eb714841f288cf51c7d942d98af6a8c6e4b01 ]

While reading sysctl_icmp_ratelimit, it can be changed concurrently.
Thus, we need to add READ_ONCE() to its reader.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

d8bcf75f

icmp: Fix data-races around sysctl. · dbf1141b

Kuniyuki Iwashima authored 2 years ago

stable inclusion
from stable-4.19.253
commit edeec63b13c252193d626c2a48d7a2f0e7016dc2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

[ Upstream commit 48d7ee321ea5182c6a70782aa186422a70e67e22 ]

While reading icmp sysctl variables, they can be changed concurrently.
So, we need to add READ_ONCE() to avoid data-races.

Fixes: 4cdf507d ("icmp: add a global rate limitation")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

dbf1141b

net: Fix data-races around sysctl_mem. · 9a58e6df

Kuniyuki Iwashima authored 2 years ago

stable inclusion
from stable-4.19.253
commit 2934b8b53d899924f30c51372dfd39b1da9be6b1
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

[ Upstream commit 310731e2f1611d1d13aae237abcf8e66d33345d5 ]

While reading .sysctl_mem, it can be changed concurrently.
So, we need to add READ_ONCE() to avoid data-races.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

9a58e6df

inetpeer: Fix data-races around sysctl. · 42248747

Kuniyuki Iwashima authored 2 years ago

stable inclusion
from stable-4.19.253
commit b5a8ebbc11df5047f9bef7bf6edb9d02f7d9baff
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

[ Upstream commit 3d32edf1f3c38d3301f6434e56316f293466d7fb ]

While reading inetpeer sysctl variables, they can be changed
concurrently.  So, we need to add READ_ONCE() to avoid data-races.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

42248747

usbnet: fix memory leak in error case · 96462b8b

Oliver Neukum authored 2 years ago

stable inclusion
from stable-4.19.252
commit d5165e657987ff4ba0ace896d4376a3718a9fbc3
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

commit b55a21b764c1e182014630fa5486d717484ac58f upstream.

usbnet_write_cmd_async() mixed up which buffers
need to be freed in which error case.

v2: add Fixes tag
v3: fix uninitialized buf pointer

Fixes: 877bd862 ("usbnet: introduce usbnet 3 command helpers")
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20220705125351.17309-1-oneukum@suse.com


Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

96462b8b

esp: limit skb_page_frag_refill use to a single page · bb6bcf7e

Sabrina Dubroca authored 2 years ago

stable inclusion
from stable-4.19.252
commit ef6f83df1209a7d9bd1c605a62457d4c00f9179e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

commit 5bd8baab087dff657e05387aee802e70304cc813 upstream.

Commit ebe48d368e97 ("esp: Fix possible buffer overflow in ESP
transformation") tried to fix skb_page_frag_refill usage in ESP by
capping allocsize to 32k, but that doesn't completely solve the issue,
as skb_page_frag_refill may return a single page. If that happens, we
will write out of bounds, despite the check introduced in the previous
patch.

This patch forces COW in cases where we would end up calling
skb_page_frag_refill with a size larger than a page (first in
esp_output_head with tailen, then in esp_output_tail with
skb->data_len).

Fixes: cac2661c ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f ("esp6: Avoid skb_cow_data whenever possible")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

bb6bcf7e

net: tun: avoid disabling NAPI twice · a6b132d2

Jakub Kicinski authored 2 years ago

stable inclusion
from stable-4.19.251
commit a12fae7621434d0360202156e13969874e002661
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

commit ff1fa2081d173b01cebe2fbf0a2d0f1cee9ce4b5 upstream.

Eric reports that syzbot made short work out of my speculative
fix. Indeed when queue gets detached its tfile->tun remains,
so we would try to stop NAPI twice with a detach(), close()
sequence.

Alternative fix would be to move tun_napi_disable() to
tun_detach_all() and let the NAPI run after the queue
has been detached.

Fixes: a8fc8cb5692a ("net: tun: stop NAPI when detaching queues")
Reported-by: syzbot <syzkaller@googlegroups.com>
Reported-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20220629181911.372047-1-kuba@kernel.org


Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

a6b132d2

net: bonding: fix use-after-free after 802.3ad slave unbind · e930a2ec

Yevhen Orlov authored 2 years ago

stable inclusion
from stable-4.19.251
commit f162f7c348fa2a5555bafdb5cc890b89b221e69c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

commit 050133e1aa2cb49bb17be847d48a4431598ef562 upstream.

commit 0622cab0 ("bonding: fix 802.3ad aggregator reselection"),
resolve case, when there is several aggregation groups in the same bond.
bond_3ad_unbind_slave will invalidate (clear) aggregator when
__agg_active_ports return zero. So, ad_clear_agg can be executed even, when
num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,
previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave
will not update slave ports list, because lag_ports==NULL. So, here we
got slave ports, pointing to freed aggregator memory.

Fix with checking actual number of ports in group (as was before
commit 0622cab0 ("bonding: fix 802.3ad aggregator reselection") ),
before ad_clear_agg().

The KASAN logs are as follows:

[  767.617392] ==================================================================
[  767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470
[  767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767
[  767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G           O 5.15.11 #15
[  767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)
[  767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler
[  767.666468] Call trace:
[  767.668930]  dump_backtrace+0x0/0x2d0
[  767.672625]  show_stack+0x24/0x30
[  767.675965]  dump_stack_lvl+0x68/0x84
[  767.679659]  print_address_description.constprop.0+0x74/0x2b8
[  767.685451]  kasan_report+0x1f0/0x260
[  767.689148]  __asan_load2+0x94/0xd0
[  767.692667]  bond_3ad_state_machine_handler+0x13dc/0x1470

Fixes: 0622cab0 ("bonding: fix 802.3ad aggregator reselection")
Co-developed-by: Maksym Glubokiy <maksym.glubokiy@plvision.eu>
Signed-off-by: Maksym Glubokiy <maksym.glubokiy@plvision.eu>
Signed-off-by: Yevhen Orlov <yevhen.orlov@plvision.eu>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Link: https://lore.kernel.org/r/20220629012914.361-1-yevhen.orlov@plvision.eu


Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

e930a2ec

net: bonding: fix possible NULL deref in rlb code · 4b48e5d4

Eric Dumazet authored 2 years ago

stable inclusion
from stable-4.19.251
commit 2c0ab68f8f1e1e1b0ef5691275cdee3eafa67833
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5I4FP


CVE: NA

--------------------------------

commit ab84db251c04d38b8dc7ee86e13d4050bedb1c88 upstream.

syzbot has two reports involving the same root cause.

bond_alb_initialize() must not set bond->alb_info.rlb_enabled
if a memory allocation error is detected.

Report 1:

general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 0 PID: 12276 Comm: kworker/u4:10 Not tainted 5.19.0-rc3-syzkaller-00132-g3b89b511ea0c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:rlb_clear_slave+0x10e/0x690 drivers/net/bonding/bond_alb.c:393
Code: 8e fc 83 fb ff 0f 84 74 02 00 00 e8 cc 2a 8e fc 48 8b 44 24 08 89 dd 48 c1 e5 06 4c 8d 34 28 49 8d 7e 14 48 89 f8 48 c1 e8 03 <42> 0f b6 14 20 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RSP: 0018:ffffc90018a8f678 EFLAGS: 00010203
RAX: 0000000000000002 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88803375bb00 RSI: ffffffff84ec4ac4 RDI: 0000000000000014
RBP: 0000000000000000 R08: 0000000000000005 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: dffffc0000000000
R13: ffff8880ac889000 R14: 0000000000000000 R15: ffff88815a668c80
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005597077e10b0 CR3: 0000000026668000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
bond_alb_deinit_slave+0x43c/0x6b0 drivers/net/bonding/bond_alb.c:1663
__bond_release_one.cold+0x383/0xd53 drivers/net/bonding/bond_main.c:2370
bond_slave_netdev_event drivers/net/bonding/bond_main.c:3778 [inline]
bond_netdev_event+0x993/0xad0 drivers/net/bonding/bond_main.c:3889
notifier_call_chain+0xb5/0x200 kernel/notifier.c:87
call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945
call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
call_netdevice_notifiers net/core/dev.c:1997 [inline]
unregister_netdevice_many+0x948/0x18b0 net/core/dev.c:10839
default_device_exit_batch+0x449/0x590 net/core/dev.c:11333
ops_exit_list+0x125/0x170 net/core/net_namespace.c:167
cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594
process_one_work+0x996/0x1610 kernel/workqueue.c:2289
worker_thread+0x665/0x1080 kernel/workqueue.c:2436
kthread+0x2e9/0x3a0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302
</TASK>

Report 2:

general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 1 PID: 5206 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-12108-g58f9d52ff689 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:rlb_req_update_slave_clients+0x109/0x2f0 drivers/net/bonding/bond_alb.c:502
Code: 5d 18 8f fc 41 80 3e 00 0f 85 a5 01 00 00 89 d8 48 c1 e0 06 49 03 84 24 68 01 00 00 48 8d 78 30 49 89 c7 48 89 fa 48 c1 ea 03 <80> 3c 2a 00 0f 85 98 01 00 00 4d 39 6f 30 75 83 e8 22 18 8f fc 49
RSP: 0018:ffffc9000300ee80 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffc90016c11000
RDX: 0000000000000006 RSI: ffffffff84eb6bf3 RDI: 0000000000000030
RBP: dffffc0000000000 R08: 0000000000000005 R09: 00000000ffffffff
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888027c80c80
R13: ffff88807d7ff800 R14: ffffed1004f901bd R15: 0000000000000000
FS:  00007f6f46c58700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 00000000516cc000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 alb_fasten_mac_swap+0x886/0xa80 drivers/net/bonding/bond_alb.c:1070
 bond_alb_handle_active_change+0x624/0x1050 drivers/net/bonding/bond_alb.c:1765
 bond_change_active_slave+0xfa1/0x29b0 drivers/net/bonding/bond_main.c:1173
 bond_select_active_slave+0x23f/0xa50 drivers/net/bonding/bond_main.c:1253
 bond_enslave+0x3b34/0x53b0 drivers/net/bonding/bond_main.c:2159
 do_set_master+0x1c8/0x220 net/core/rtnetlink.c:2577
 rtnl_newlink_create net/core/rtnetlink.c:3380 [inline]
 __rtnl_newlink+0x13ac/0x17e0 net/core/rtnetlink.c:3580
 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3593
 rtnetlink_rcv_msg+0x43a/0xc90 net/core/rtnetlink.c:6089
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:734
 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2546
 __sys_sendmsg net/socket.c:2575 [inline]
 __do_sys_sendmsg net/socket.c:2584 [inline]
 __se_sys_sendmsg net/socket.c:2582 [inline]
 __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f6f45a89109
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f6f46c58168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f6f45b9c030 RCX: 00007f6f45a89109
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000006
RBP: 00007f6f45ae308d R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffed99029af R14: 00007f6f46c58300 R15: 0000000000022000
 </TASK>

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jay Vosburgh <j.vosburgh@gmail.com>
Cc: Veaceslav Falico <vfalico@gmail.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Link: https://lore.kernel.org/r/20220627102813.126264-1-edumazet@google.com


Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>

4b48e5d4