提交 · 4.19.90-2306.5.0 · openeuler / Kernel

27 6月, 2023 3 次提交

HID: intel_ish-hid: Add check for ishtp_dma_tx_map · 3a150360

由 Jiasheng Jiang 提交于 6月 27, 2023

stable inclusion
from stable-v4.19.272
commit cc906a3a4432da143ab3d2e894f99ddeff500cd3
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FCLX
CVE: CVE-2023-3358

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=722c156c6eab40a6e7dda98dfa66724f9d5aeceb

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

[ Upstream commit b3d40c3e ]

As the kcalloc may return NULL pointer,
it should be better to check the ishtp_dma_tx_map
before use in order to avoid NULL pointer dereference.

Fixes: 3703f53b ("HID: intel_ish-hid: ISH Transport layer")
Signed-off-by: NJiasheng Jiang <jiasheng@iscas.ac.cn>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NCai Xinchen <caixinchen1@huawei.com>
Reviewed-by: GUO Zihua<guozihua@huawei.com>
Reviewed-by: NGONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

3a150360

media: saa7134: fix use after free bug in saa7134_finidev due to race condition · 51b2eb79

由 Zheng Wang 提交于 6月 27, 2023

stable inclusion
from stable-v4.19.283
commit 95e684340470a95ff4957cb9a536ec7a0461c75b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ERIV
CVE: CVE-2023-3327

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

[ Upstream commit 30cf57da ]

In saa7134_initdev, it will call saa7134_hwinit1. There are three
function invoking here: saa7134_video_init1, saa7134_ts_init1
and saa7134_vbi_init1.

All of them will init a timer with same function. Take
saa7134_video_init1 as an example. It'll bound &dev->video_q.timeout
with saa7134_buffer_timeout.

In buffer_activate, the timer funtcion is started.

If we remove the module or device which will call saa7134_finidev
to make cleanup, there may be a unfinished work. The
possible sequence is as follows, which will cause a
typical UAF bug.

Fix it by canceling the timer works accordingly before cleanup in
saa7134_finidev.

CPU0                  CPU1

                    |saa7134_buffer_timeout
saa7134_finidev     |
  kfree(dev);       |
                    |
                    | saa7134_buffer_next
                    | //use dev

Fixes: 1e7126b4 ("media: saa7134: Convert timers to use timer_setup()")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLonglong Xia <xialonglong1@huawei.com>
Reviewed-by: NNanyong Sun <sunnanyong@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

51b2eb79

config: enable CONFIG_QOS_SCHED_SMART_GRID by default · 7660f27a

由 Wang ShaoBo 提交于 6月 27, 2023

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7G6SW
CVE: NA

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

set config CONFIG_QOS_SCHED_SMART_GRID default value.
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Reviewed-by: NChao Liu <liuchao173@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

7660f27a

26 6月, 2023 2 次提交

mm: oom: move memcg_print_bad_task() out of mem_cgroup_scan_tasks() · 905927d9

由 Kang Chen 提交于 6月 26, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NYW4
CVE: NA

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

raw call flow:

oom_kill_process
  -> mem_cgroup_scan_tasks(.., .., message)
    -> memcg_print_bad_task(message, ..)

message is "const char*" type, and incorrectly cast to
"oom_control*" type in memcg_print_bad_task.

Fix it by moving memcg_print_bad_task out of mem_cgroup_scan_tasks
and call it in select_bad_process and dump_tasks. Furthermore,
use struct oom_control* directly and remove the useless parm `ret`.
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NKang Chen <void0red@hust.edu.cn>
(cherry picked from commit 789038c7)

Conflicts:
	include/linux/memcontrol.h
	[Add declaration of memcg_print_bad_task()]
	mm/memcontrol.c
	mm/oom_kill.c
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

905927d9

media: dm1105: Fix use after free bug in dm1105_remove due to race condition · 4ababe0b

由 Zheng Wang 提交于 6月 26, 2023

stable inclusion
from stable-v4.19.283
commit 722c156c6eab40a6e7dda98dfa66724f9d5aeceb
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDYO
CVE: CVE-2023-35824

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=722c156c6eab40a6e7dda98dfa66724f9d5aeceb

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

[ Upstream commit 5abda7a1 ]

In dm1105_probe, it called dm1105_ir_init and bound
&dm1105->ir.work with dm1105_emit_key.
When it handles IRQ request with dm1105_irq,
it may call schedule_work to start the work.

When we call dm1105_remove to remove the driver, there
may be a sequence as follows:

Fix it by finishing the work before cleanup in dm1105_remove

CPU0                  CPU1

                    |dm1105_emit_key
dm1105_remove      |
  dm1105_ir_exit       |
    rc_unregister_device |
    rc_free_device  |
    rc_dev_release  |
    kfree(dev);     |
                    |
                    | rc_keydown
                    |   //use

Fixes: 34d2f9bf ("V4L/DVB: dm1105: use dm1105_dev & dev instead of dm1105dvb")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NPu Lehui <pulehui@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

4ababe0b

25 6月, 2023 2 次提交

sched: Fix memory leak for smart grid · 2b5d1aa5

由 Hui Tang 提交于 6月 25, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7FBJM
CVE: NA

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

Free ad->domains_orig[] in 'free_affinity_domains',
otherwise the memory will leak.

Fixes: 713cfd26 ("sched: Introduce smart grid scheduling strategy for cfs")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

2b5d1aa5

sched: Delete redundant updates to p->prefer_cpus · 4f3df479

由 Hui Tang 提交于 6月 25, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7F7KV
CVE: NA

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

Delete redundant updates to p->prefer_cpus when smart grid used.
Add missed check for p->prefer_cpus when !CONFIG_QOS_SCHED_SMART_GRID.

Fixes: 21e5d85e ("sched: Fix possible deadlock in tg_set_dynamic_affinity_mode")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

4f3df479

21 6月, 2023 5 次提交

nbd: fix incomplete validation of ioctl arg · df4418ec

由 Zhong Jinghua 提交于 6月 21, 2023

mainline inclusion
from mainline-v6.4-rc1
commit 55793ea5
category: bugfix
bugzilla: 188268, https://gitee.com/openeuler/kernel/issues/I6DC67
CVE: NA

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

We tested and found an alarm caused by nbd_ioctl arg without verification.
The UBSAN warning calltrace like below:

UBSAN: Undefined behaviour in fs/buffer.c:1709:35
signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long long int'
CPU: 3 PID: 2523 Comm: syz-executor.0 Not tainted 4.19.90 #1
Hardware name: linux,dummy-virt (DT)
Call trace:
 dump_backtrace+0x0/0x3f0 arch/arm64/kernel/time.c:78
 show_stack+0x28/0x38 arch/arm64/kernel/traps.c:158
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x170/0x1dc lib/dump_stack.c:118
 ubsan_epilogue+0x18/0xb4 lib/ubsan.c:161
 handle_overflow+0x188/0x1dc lib/ubsan.c:192
 __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:206
 __block_write_full_page+0x94c/0xa20 fs/buffer.c:1709
 block_write_full_page+0x1f0/0x280 fs/buffer.c:2934
 blkdev_writepage+0x34/0x40 fs/block_dev.c:607
 __writepage+0x68/0xe8 mm/page-writeback.c:2305
 write_cache_pages+0x44c/0xc70 mm/page-writeback.c:2240
 generic_writepages+0xdc/0x148 mm/page-writeback.c:2329
 blkdev_writepages+0x2c/0x38 fs/block_dev.c:2114
 do_writepages+0xd4/0x250 mm/page-writeback.c:2344

The reason for triggering this warning is __block_write_full_page()
-> i_size_read(inode) - 1 overflow.
inode->i_size is assigned in __nbd_ioctl() -> nbd_set_size() -> bytesize.
We think it is necessary to limit the size of arg to prevent errors.

Moreover, __nbd_ioctl() -> nbd_add_socket(), arg will be cast to int.
Assuming the value of arg is 0x80000000000000001) (on a 64-bit machine),
it will become 1 after the coercion, which will return unexpected results.

Fix it by adding checks to prevent passing in too large numbers.
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20230206145805.2645671-1-zhongjinghua@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

df4418ec

nbd: validate the block size in nbd_set_size · 25541f00

由 Christoph Hellwig 提交于 6月 21, 2023

mainline inclusion
from mainline-v5.1-rc1
commit dcbddf54
category: bugfix
bugzilla: 188268, https://gitee.com/openeuler/kernel/issues/I6DC67
CVE: NA

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

Move the validation of the block from the callers into nbd_set_size.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NJosef Bacik <josef@toxicpanda.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

conflict:
	drivers/block/nbd.c
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

25541f00

relayfs: fix out-of-bounds access in relay_file_read · b99f764b

由 Zhang Zhengming 提交于 6月 21, 2023

stable inclusion
from stable-v4.19.283
commit ed32488417669568308b65ba5d45799418f9ed49
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7E5C1
CVE: CVE-2023-3268

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

[ Upstream commit 43ec16f1 ]

There is a crash in relay_file_read, as the var from
point to the end of last subbuf.

The oops looks something like:
pc : __arch_copy_to_user+0x180/0x310
lr : relay_file_read+0x20c/0x2c8
Call trace:
 __arch_copy_to_user+0x180/0x310
 full_proxy_read+0x68/0x98
 vfs_read+0xb0/0x1d0
 ksys_read+0x6c/0xf0
 __arm64_sys_read+0x20/0x28
 el0_svc_common.constprop.3+0x84/0x108
 do_el0_svc+0x74/0x90
 el0_svc+0x1c/0x28
 el0_sync_handler+0x88/0xb0
 el0_sync+0x148/0x180

We get the condition by analyzing the vmcore:

1). The last produced byte and last consumed byte
    both at the end of the last subbuf

2). A softirq calls function(e.g __blk_add_trace)
    to write relay buffer occurs when an program is calling
    relay_file_read_avail().

        relay_file_read
                relay_file_read_avail
                        relay_file_read_consume(buf, 0, 0);
                        //interrupted by softirq who will write subbuf
                        ....
                        return 1;
                //read_start point to the end of the last subbuf
                read_start = relay_file_read_start_pos
                //avail is equal to subsize
                avail = relay_file_read_subbuf_avail
                //from  points to an invalid memory address
                from = buf->start + read_start
                //system is crashed
                copy_to_user(buffer, from, avail)

Link: https://lkml.kernel.org/r/20230419040203.37676-1-zhang.zhengming@h3c.com
Fixes: 8d62fdeb ("relay file read: start-pos fix")
Signed-off-by: NZhang Zhengming <zhang.zhengming@h3c.com>
Reviewed-by: NZhao Lei <zhao_lei1@hoperun.com>
Reviewed-by: NZhou Kete <zhou.kete@h3c.com>
Reviewed-by: NPengcheng Yang <yangpc@wangsu.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

b99f764b

kernel/relay.c: fix read_pos error when multiple readers · 1eb719bf

由 Pengcheng Yang 提交于 6月 21, 2023

stable inclusion
from stable-v4.19.283
commit 2a6c63d04d89227ee45d0234c8059e2bccc15d73
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7E5C1
CVE: CVE-2023-3268

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

[ Upstream commit 341a7213 ]

When reading, read_pos should start with bytes_consumed, not file->f_pos.
Because when there is more than one reader, the read_pos corresponding to
file->f_pos may have been consumed, which will cause the data that has
been consumed to be read and the bytes_consumed update error.
Signed-off-by: NPengcheng Yang <yangpc@wangsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Reviewed-by: NJens Axboe <axboe@kernel.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jann Horn <jannh@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>e
Link: http://lkml.kernel.org/r/1579691175-28949-1-git-send-email-yangpc@wangsu.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Stable-dep-of: 43ec16f1 ("relayfs: fix out-of-bounds access in relay_file_read")
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

1eb719bf

net/sched: flower: fix possible OOB write in fl_set_geneve_opt() · 5cce350a

由 Hangyu Hua 提交于 6月 21, 2023

stable inclusion
from stable-v4.19.285
commit 59a27414bb00e48c4153a8b794fb4e69910a6a1b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7E6ML
CVE: CVE-2023-35788

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=59a27414bb00e48c4153a8b794fb4e69910a6a1b

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

[ Upstream commit 4d56304e ]

If we send two TCA_FLOWER_KEY_ENC_OPTS_GENEVE packets and their total
size is 252 bytes(key->enc_opts.len = 252) then
key->enc_opts.len = opt->length = data_len / 4 = 0 when the third
TCA_FLOWER_KEY_ENC_OPTS_GENEVE packet enters fl_set_geneve_opt. This
bypasses the next bounds check and results in an out-of-bounds.

Fixes: 0a6e7778 ("net/sched: allow flower to match tunnel options")
Signed-off-by: NHangyu Hua <hbh25y@gmail.com>
Reviewed-by: NSimon Horman <simon.horman@corigine.com>
Reviewed-by: NPieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com>
Link: https://lore.kernel.org/r/20230531102805.27090-1-hbh25y@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

5cce350a

20 6月, 2023 6 次提交

sched: Adjust few parameters range for smart grid · 27c8c87a

由 Hui Tang 提交于 6月 20, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7EEF3
CVE: NA

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

Adjust few parameters range for smart grid.

Fixes: 713cfd26 ("sched: Introduce smart grid scheduling strategy for cfs")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

27c8c87a

sched: clear credit count in error branch · 82caaaf4

由 Hui Tang 提交于 6月 20, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7EBSH
CVE: NA

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

Clear credit count if sched_prefer_cpus_fork failed.

Fixes: 243865da ("cpuset: Introduce new interface for scheduler dynamic affinity")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

82caaaf4

sched: Fix memory leak on error branch · d791cf33

由 Hui Tang 提交于 6月 20, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7EBNA
CVE: NA

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

Fix memory leak on error branch for smart grid.

Fixes: 713cfd26 ("sched: Introduce smart grid scheduling strategy for cfs")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

d791cf33

sched: fix dereference NULL pointers · b43a1c9e

由 Hui Tang 提交于 6月 20, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7EA1X
CVE: NA

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

tg->auto_affinity is NULL if init_auto_affinity() failed.
So add checking for tg->auto_affinity before derefrence.

Fixes: 713cfd26 ("sched: Introduce smart grid scheduling strategy for cfs")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

b43a1c9e

sched: Fix timer storm for smart grid · 12521356

由 Hui Tang 提交于 6月 20, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7DSX6
CVE: NA

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

Timer storm may be triggered if !cpumask_weight(ad->domains[i])
which is set in cpu offline.

Fixes: 713cfd26 ("sched: Introduce smart grid scheduling strategy for cfs")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

12521356

memstick: r592: Fix UAF bug in r592_remove due to race condition · b6dc4c1d

由 Zheng Wang 提交于 6月 20, 2023

mainline inclusion
from mainline-v6.4-rc1
commit 63264422
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7EK74
CVE: CVE-2023-3141

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

In r592_probe, dev->detect_timer was bound with r592_detect_timer.
In r592_irq function, the timer function will be invoked by mod_timer.

If we remove the module which will call hantro_release to make cleanup,
there may be a unfinished work. The possible sequence is as follows,
which will cause a typical UAF bug.

Fix it by canceling the work before cleanup in r592_remove.

CPU0                  CPU1

                    |r592_detect_timer
r592_remove         |
  memstick_free_host|
  put_device;       |
  kfree(host);      |
                    |
                    | queue_work
                    |   &host->media_checker //use
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Link: https://lore.kernel.org/r/20230307164338.1246287-1-zyytlz.wz@163.comSigned-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

b6dc4c1d

19 6月, 2023 2 次提交

fbcon: Check font dimension limits · 513128e2

由 Samuel Thibault 提交于 6月 19, 2023

mainline inclusion
from mainline-v6.2-rc7
commit 2b09d5d3
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7C2TM
CVE: CVE-2023-3161

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b09d5d364986f724f17001ccfe4126b9b43a0be

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

blit_x and blit_y are u32, so fbcon currently cannot support fonts
larger than 32x32.

The 32x32 case also needs shifting an unsigned int, to properly set bit
31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
as reported on:

http://lore.kernel.org/all/IA1PR07MB98308653E259A6F2CE94A4AFABCE9@IA1PR07MB9830.namprd07.prod.outlook.com
Kernel Branch: 6.2.0-rc5-next-20230124
Kernel config: https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
Reproducer: https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharingReported-by: NSanan Hasanov <sanan.hasanov@Knights.ucf.edu>
Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
Fixes: 2d2699d9 ("fbcon: font setting should check limitation of driver")
Cc: stable@vger.kernel.org
Tested-by: NMiko Larsson <mikoxyzzz@gmail.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: Nyongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

513128e2

sched/rt: Fix possible warn when push_rt_task · 3e40e3aa

由 Hui Tang 提交于 6月 19, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7DX9Y
CVE: NA

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

A warn may be triggered during reboot, as follows:

reboot
  ->kernel_restart
    ->machine_restart
      ->smp_send_stop --- ipi handler set_cpu_online(cpu, false)

balance_callback
-> __balance_callback
  ->push_rt_task
    -> find_lock_lowest_rq <从vec->mask获取的rq>
      -> find_lowest_rq
        -> cpupri_find
          -> cpupri_find_fitness
            -> __cpupri_find [cpumask_and(..., vec->mask)]
    -> set_task_cpu(next_task, lowest_rq->cpu) --- WARN_ON(!oneline(cpu)

So add !cpu_online(lowest_rq->cpu) check before set_task_cpu().
The fix does not completely fix the problem, since cpu_online_mask may
be cleared after check.

Fixes: 4ff9083b ("sched/core: WARN() when migrating to an offline CPU")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

3e40e3aa

16 6月, 2023 2 次提交

!1152 pci: workaround multiple functions can be assigned to only one VM · 0822bf62

由 openeuler-ci-bot 提交于 6月 16, 2023

Merge Pull Request from: @duanqiangwen

Merged in olk-5.10 and 22.03-LTS
sync to 1.0-LTS

This PR is to workaround if multiple functions on a Beijing Wangxun PCl device belong to the same lOMMU group,
they can be directly assigned to only one VM as well, letting multiple functions
belong to different IOMMU group.

Issue：#I66W4Y:[openEuler-22.03-LTS][openEuler-22.03-LTS-SP1]Make Multiple functions On Beijing Wangxun PCIE NIC belong to different IOMMU group:[openEuler-22.03-LTS][openEuler-22.03-LTS-SP1]Make Multiple functions On Beijing Wangxun PCIE NIC belong to different IOMMU group

Hardware List:
Netswift All Nic, PCI vendor ID 0x8088

Net-Swift Official Website:
https://www.net-swift.com

Link:https://gitee.com/openeuler/kernel/pulls/1152

Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>

0822bf62

pci: workaround multiple functions can be assigned to only one VM · cfeb87ad

由 Duanqiang Wen 提交于 6月 16, 2023

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I66W4Y
CVE: NA

workaround if multiple functions on a PCl device belong to the same
IOMMU group, they can be directly assigned to only one VM as well,
letting multiple functions belong to different IOMMU group.
Signed-off-by: NDuanqiang Wen <duanqiangwen@net-swift.com>

cfeb87ad

15 6月, 2023 9 次提交

sched: Fix negative count for jump label · cde6dbb8

由 Hui Tang 提交于 6月 15, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7DA63
CVE: NA

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

Add mutex lock to prevent negative count for jump label.

[28612.530675] ------------[ cut here ]------------
[28612.532708] jump label: negative count!
[28612.535031] WARNING: CPU: 4 PID: 3899 at kernel/jump_label.c:202
	__static_key_slow_dec_cpuslocked+0x204/0x240
[28612.538216] Kernel panic - not syncing: panic_on_warn set ...
[28612.538216]
[28612.540487] CPU: 4 PID: 3899 Comm: sh Kdump: loaded Not tainted
[28612.542788] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[28612.546455] Call Trace:
[28612.547339]  dump_stack+0xc6/0x11e
[28612.548546]  ? __static_key_slow_dec_cpuslocked+0x200/0x240
[28612.550352]  panic+0x1d6/0x46b
[28612.551375]  ? refcount_error_report+0x2a5/0x2a5
[28612.552915]  ? kmsg_dump_rewind_nolock+0xde/0xde
[28612.554358]  ? sched_clock_cpu+0x18/0x1b0
[28612.555699]  ? __warn+0x1d1/0x210
[28612.556799]  ? __static_key_slow_dec_cpuslocked+0x204/0x240
[28612.558548]  __warn+0x1ec/0x210
[28612.559621]  ? __static_key_slow_dec_cpuslocked+0x204/0x240
[28612.561536]  report_bug+0x1ee/0x2b0
[28612.562706]  fixup_bug.part.4+0x37/0x80
[28612.563937]  do_error_trap+0x21c/0x260
[28612.565109]  ? fixup_bug.part.4+0x80/0x80
[28612.566453]  ? check_preemption_disabled+0x34/0x1f0
[28612.567991]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[28612.569534]  ? lockdep_hardirqs_off+0x1cb/0x2b0
[28612.570993]  ? error_entry+0x9a/0x130
[28612.572138]  ? trace_hardirqs_off_caller+0x59/0x1a0
[28612.573710]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[28612.575232]  invalid_op+0x14/0x20
[root@lo[ca2lh8ost6 12.576387]  ? vprintk_func+0x68/0x1a0
[28612.577827]  ? __static_key_slow_dec_cpuslocked+0x204/0x240
smartg[ri2d]8# 612.579662]  ? __static_key_slow_dec_cpuslocked+0x204/0x240
[28612.581781]  ? static_key_disable+0x30/0x30
[28612.583248]  ? s
tatic_key_slow_dec+0x57/0x90
[28612.584997]  ? tg_set_dynamic_affinity_mode+0x42/0x70
[28612.586714]  ? cgroup_file_write+0x471/0x6a0
[28612.588162]  ? cgroup_css.part.4+0x100/0x100
[28612.589579]  ? cgroup_css.part.4+0x100/0x100
[28612.591031]  ? kernfs_fop_write+0x2af/0x430
[28612.592625]  ? kernfs_vma_page_mkwrite+0x230/0x230
[28612.594274]  ? __vfs_write+0xef/0x680
[28612.595590]  ? kernel_read+0x110/0x110
ea8612.596899]  ? check_preemption_disabled+0x3mkd4ir/: 0canxno1t fcr0
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

cde6dbb8

sched: Fix possible deadlock in tg_set_dynamic_affinity_mode · 21e5d85e

由 Hui Tang 提交于 6月 15, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7CGD0
CVE: NA

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

Deadlock occurs in two situations as follows:

The first case:

tg_set_dynamic_affinity_mode    --- raw_spin_lock_irq(&auto_affi->lock);
	->start_auto_affintiy   --- trigger timer
		->tg_update_task_prefer_cpus
			>css_task_inter_next
				->raw_spin_unlock_irq

hr_timer_run_queues
  ->sched_auto_affi_period_timer --- try spin lock (&auto_affi->lock)

The second case as follows:

[  291.470810] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[  291.472715] rcu:     1-...0: (0 ticks this GP) idle=a6a/1/0x4000000000000002 softirq=78516/78516 fqs=5249
[  291.475268] rcu:     (detected by 6, t=21006 jiffies, g=202169, q=9862)
[  291.477038] Sending NMI from CPU 6 to CPUs 1:
[  291.481268] NMI backtrace for cpu 1
[  291.481273] CPU: 1 PID: 1923 Comm: sh Kdump: loaded Not tainted 4.19.90+ #150
[  291.481278] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
[  291.481281] RIP: 0010:queued_spin_lock_slowpath+0x136/0x9a0
[  291.481289] Code: c0 74 3f 49 89 dd 48 89 dd 48 b8 00 00 00 00 00 fc ff df 49 c1 ed 03 83 e5 07 49 01 c5 83 c5 03 48 83 05 c4 66 b9 05 01 f3 90 <41> 0f b6 45 00 40 38 c5 7c 08 84 c0 0f 85 ad 07 00 00 0
[  291.481292] RSP: 0018:ffff88801de87cd8 EFLAGS: 00000002
[  291.481297] RAX: 0000000000000101 RBX: ffff888001be0a28 RCX: ffffffffb8090f7d
[  291.481301] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888001be0a28
[  291.481304] RBP: 0000000000000003 R08: ffffed100037c146 R09: ffffed100037c146
[  291.481307] R10: 000000001106b143 R11: ffffed100037c145 R12: 1ffff11003bd0f9c
[  291.481311] R13: ffffed100037c145 R14: fffffbfff7a38dee R15: dffffc0000000000
[  291.481315] FS:  00007fac4f306740(0000) GS:ffff88801de80000(0000) knlGS:0000000000000000
[  291.481318] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  291.481321] CR2: 00007fac4f4bb650 CR3: 00000000046b6000 CR4: 00000000000006e0
[  291.481323] Call Trace:
[  291.481324]  <IRQ>
[  291.481326]  ? osq_unlock+0x2a0/0x2a0
[  291.481329]  ? check_preemption_disabled+0x4c/0x290
[  291.481331]  ? rcu_accelerate_cbs+0x33/0xed0
[  291.481333]  _raw_spin_lock_irqsave+0x83/0xa0
[  291.481336]  sched_auto_affi_period_timer+0x251/0x820
[  291.481338]  ? __remove_hrtimer+0x151/0x200
[  291.481340]  __hrtimer_run_queues+0x39d/0xa50
[  291.481343]  ? tg_update_affinity_domain_down+0x460/0x460
[  291.481345]  ? enqueue_hrtimer+0x2e0/0x2e0
[  291.481348]  ? ktime_get_update_offsets_now+0x1d7/0x2c0
[  291.481350]  hrtimer_run_queues+0x243/0x470
[  291.481352]  run_local_timers+0x5e/0x150
[  291.481354]  update_process_times+0x36/0xb0
[  291.481357]  tick_sched_handle.isra.4+0x7c/0x180
[  291.481359]  tick_nohz_handler+0xd1/0x1d0
[  291.481365]  smp_apic_timer_interrupt+0x12c/0x4e0
[  291.481368]  apic_timer_interrupt+0xf/0x20
[  291.481370]  </IRQ>
[  291.481372]  ? smp_call_function_many+0x68c/0x840
[  291.481375]  ? smp_call_function_many+0x6ab/0x840
[  291.481377]  ? arch_unregister_cpu+0x60/0x60
[  291.481379]  ? native_set_fixmap+0x100/0x180
[  291.481381]  ? arch_unregister_cpu+0x60/0x60
[  291.481384]  ? set_task_select_cpus+0x116/0x940
[  291.481386]  ? smp_call_function+0x53/0xc0
[  291.481388]  ? arch_unregister_cpu+0x60/0x60
[  291.481390]  ? on_each_cpu+0x49/0xf0
[  291.481393]  ? set_task_select_cpus+0x115/0x940
[  291.481395]  ? text_poke_bp+0xff/0x180
[  291.481397]  ? poke_int3_handler+0xc0/0xc0
[  291.481400]  ? __set_prefer_cpus_ptr.constprop.4+0x1cd/0x900
[  291.481402]  ? hrtick+0x1b0/0x1b0
[  291.481404]  ? set_task_select_cpus+0x115/0x940
[  291.481407]  ? __jump_label_transform.isra.0+0x3a1/0x470
[  291.481409]  ? kernel_init+0x280/0x280
[  291.481411]  ? kasan_check_read+0x1d/0x30
[  291.481413]  ? mutex_lock+0x96/0x100
[  291.481415]  ? __mutex_lock_slowpath+0x30/0x30
[  291.481418]  ? arch_jump_label_transform+0x52/0x80
[  291.481420]  ? set_task_select_cpus+0x115/0x940
[  291.481422]  ? __jump_label_update+0x1a1/0x1e0
[  291.481424]  ? jump_label_update+0x2ee/0x3b0
[  291.481427]  ? static_key_slow_inc_cpuslocked+0x1c8/0x2d0
[  291.481430]  ? start_auto_affinity+0x190/0x200
[  291.481432]  ? tg_set_dynamic_affinity_mode+0xad/0xf0
[  291.481435]  ? cpu_affinity_mode_write_u64+0x22/0x30
[  291.481437]  ? cgroup_file_write+0x46f/0x660
[  291.481439]  ? cgroup_init_cftypes+0x300/0x300
[  291.481441]  ? __mutex_lock_slowpath+0x30/0x30
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

21e5d85e

sched: fix WARN found by deadlock detect · 217edab9

由 Hui Tang 提交于 6月 15, 2023

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQZ0
CVE: NA

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

The WARNING report when run:
echo 1 > /sys/fs/cgroup/cpu/cpu.dynamic_affinity_mode

[  147.276757] WARNING: CPU: 5 PID: 1770 at kernel/cpu.c:326 \
	lockdep_assert_cpus_held+0xac/0xd0
[  147.279670] Kernel panic - not syncing: panic_on_warn set ...
[  147.279670]
[  147.282211] CPU: 5 PID: 1770 Comm: bash Kdump: loaded Not tainted 4.19
[  147.284796] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)..
[  147.290963] Call Trace:
[  147.292459]  dump_stack+0xc6/0x11e
[  147.294295]  ? lockdep_assert_cpus_held+0xa0/0xd0
[  147.296876]  panic+0x1d6/0x46b
[  147.298591]  ? refcount_error_report+0x2a5/0x2a5
[  147.301131]  ? kmsg_dump_rewind_nolock+0xde/0xde
[  147.303738]  ? sched_clock_cpu+0x18/0x1b0
[  147.305943]  ? __warn+0x1d1/0x210
[  147.307831]  ? lockdep_assert_cpus_held+0xac/0xd0
[  147.310469]  __warn+0x1ec/0x210
[  147.312271]  ? lockdep_assert_cpus_held+0xac/0xd0
[  147.314838]  report_bug+0x1ee/0x2b0
[  147.316798]  fixup_bug.part.4+0x37/0x80
[  147.318946]  do_error_trap+0x21c/0x260
[  147.321062]  ? fixup_bug.part.4+0x80/0x80
[  147.323253]  ? check_preemption_disabled+0x34/0x1f0
[  147.324886]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[  147.326277]  ? lockdep_hardirqs_off+0x1cb/0x2b0
[  147.327505]  ? error_entry+0x9a/0x130
[  147.328523]  ? trace_hardirqs_off_caller+0x59/0x1a0
[  147.329844]  ? trace_hardirqs_off_thunk+0x1a/0x1c
[  147.331124]  invalid_op+0x14/0x20
[  147.332057]  ? vprintk_func+0x68/0x1a0
[  147.333082]  ? lockdep_assert_cpus_held+0xac/0xd0
[  147.334355]  ? lockdep_assert_cpus_held+0xac/0xd0
[  147.335624]  ? static_key_slow_inc_cpuslocked+0x5a/0x230
[  147.337079]  ? tg_set_dynamic_affinity_mode+0x4f/0x70
[  147.338444]  ? cgroup_file_write+0x471/0x6a0
[  147.339604]  ? cgroup_css.part.4+0x100/0x100
[  147.340782]  ? cgroup_css.part.4+0x100/0x100
[  147.341943]  ? kernfs_fop_write+0x2af/0x430
[  147.343083]  ? kernfs_vma_page_mkwrite+0x230/0x230
[  147.344401]  ? __vfs_write+0xef/0x680
[  147.345404]  ? kernel_read+0x110/0x110
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

217edab9

sched: fix smart grid usage count · d9099163

由 Hui Tang 提交于 6月 15, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7D98G
CVE: NA

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

smart_grid_usage_dec() should called when free taskgroup
if the mode is auto.
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

d9099163

sched: Add static key to reduce noise · 373fd236

由 Hui Tang 提交于 6月 15, 2023

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

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

Add static key to reduce noise when not enable dynamic affinity.
There are better performance in some case, such for lmbench.

Fixes: 243865da ("cpuset: Introduce new interface for scheduler ...")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

373fd236

net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment() · 822fb46b

由 Dong Chenchen 提交于 6月 15, 2023

stable inclusion
from stable-v4.19.283
commit d2309e0cb27b6871b273fbc1725e93be62570d86
category: bugfix
bugzilla: 188702, https://gitee.com/openeuler/kernel/issues/I7DUPI
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d2309e0cb27b6871b273fbc1725e93be62570d86

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

[ Upstream commit c83b4938 ]

As the call trace shows, skb_panic was caused by wrong skb->mac_header
in nsh_gso_segment():

invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1
RIP: 0010:skb_panic+0xda/0xe0
call Trace:
 skb_push+0x91/0xa0
 nsh_gso_segment+0x4f3/0x570
 skb_mac_gso_segment+0x19e/0x270
 __skb_gso_segment+0x1e8/0x3c0
 validate_xmit_skb+0x452/0x890
 validate_xmit_skb_list+0x99/0xd0
 sch_direct_xmit+0x294/0x7c0
 __dev_queue_xmit+0x16f0/0x1d70
 packet_xmit+0x185/0x210
 packet_snd+0xc15/0x1170
 packet_sendmsg+0x7b/0xa0
 sock_sendmsg+0x14f/0x160

The root cause is:
nsh_gso_segment() use skb->network_header - nhoff to reset mac_header
in skb_gso_error_unwind() if inner-layer protocol gso fails.
However, skb->network_header may be reset by inner-layer protocol
gso function e.g. mpls_gso_segment. skb->mac_header reset by the
inaccurate network_header will be larger than skb headroom.

nsh_gso_segment
    nhoff = skb->network_header - skb->mac_header;
    __skb_pull(skb,nsh_len)
    skb_mac_gso_segment
        mpls_gso_segment
            skb_reset_network_header(skb);//skb->network_header+=nsh_len
            return -EINVAL;
    skb_gso_error_unwind
        skb_push(skb, nsh_len);
        skb->mac_header = skb->network_header - nhoff;
        // skb->mac_header > skb->headroom, cause skb_push panic

Use correct mac_offset to restore mac_header and get rid of nhoff.

Fixes: c411ed85 ("nsh: add GSO support")
Reported-by: syzbot+632b5d9964208bfef8c0@syzkaller.appspotmail.com
Suggested-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

822fb46b

!1134 【openEuler-1.0-LTS】cpufreq:conservative: Fix load in fast_dbs_update() · f59c1a3e

由 openeuler-ci-bot 提交于 6月 15, 2023

Merge Pull Request from: @xuesinian

Remove "dbs_update(policy)" for getting load in fast_dbs_update(), incoming "load" from cs_dbs_update().

Load results are inaccurate after two consecutive updates, resulting in inaccurate frequency scaling.

Related issue : #I7DJU2

Link:https://gitee.com/openeuler/kernel/pulls/1134

Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>

f59c1a3e

firewire: fix potential uaf in outbound_phy_packet_callback() · 160e0014

由 Chengfeng Ye 提交于 6月 15, 2023

stable inclusion
from stable-v4.19.242
commit 34380b5647f13fecb458fea9a3eb3d8b3a454709
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7BYU9
CVE: CVE-2023-3159

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=34380b5647f1

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

commit b7c81f80 upstream.

&e->event and e point to the same address, and &e->event could
be freed in queue_event. So there is a potential uaf issue if
we dereference e after calling queue_event(). Fix this by adding
a temporary variable to maintain e->client in advance, this can
avoid the potential uaf issue.

Cc: <stable@vger.kernel.org>
Signed-off-by: NChengfeng Ye <cyeaa@connect.ust.hk>
Signed-off-by: NTakashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20220409041243.603210-2-o-takashi@sakamocchi.jpSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

160e0014

cpufreq: conservative: fix load in fast_dbs_update() · 0dfa77a2

由 XueSinian 提交于 6月 14, 2023

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7DJU2
CVE: NA

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

Remove "dbs_update(policy)" for getting load in fast_dbs_update(),
incoming load from cs_dbs_update().

Reason:
Load results are inaccurate after two consecutive updates, resulting
in inaccurate frequency scaling.

Fixes: 75704b66 ("cpufreq: conservative: Add a switch to enable fast mode")
Signed-off-by: NXue Sinian <xuesinian@huawei.com>

0dfa77a2

12 6月, 2023 5 次提交

arm64: Add AMPERE1 to the Spectre-BHB affected list · 0211ac08

由 D Scott Phillips 提交于 6月 12, 2023

stable inclusion
from stable-v5.10.153
commit 52a43b82006dc88f996bd06da5a3fcfef85220c8
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I79V8S
CVE: CVE-2023-3006

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=52a43b82006dc88f996bd06da5a3fcfef85220c8

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

Per AmpereOne erratum AC03_CPU_12, "Branch history may allow control of
speculative execution across software contexts," the AMPERE1 core needs the
bhb clearing loop to mitigate Spectre-BHB, with a loop iteration count of
11.
Signed-off-by: ND Scott Phillips <scott@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20221011022140.432370-1-scott@os.amperecomputing.comReviewed-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>

conflicts:
    arch/arm64/include/asm/cputype.h
    arch/arm64/kernel/proton-pack.c
Signed-off-by: NLin Yujun <linyujun809@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

0211ac08

sctp: Call inet6_destroy_sock() via sk->sk_destruct(). · 31b82122

由 Kuniyuki Iwashima 提交于 6月 12, 2023

stable inclusion
from stable-v4.19.282
commit 8af86ad54d3bb01548c19c0466cf732008dbabe6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8af86ad54d3bb01548c19c0466cf732008dbabe6

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

commit 6431b0f6 upstream.

After commit d38afeec ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.

SCTP sets its own sk->sk_destruct() in the sctp_init_sock(), and
SCTPv6 socket reuses it as the init function.

To call inet6_sock_destruct() from SCTPv6 sk->sk_destruct(), we
set sctp_v6_destruct_sock() in a new init function.
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

31b82122

net: Remove WARN_ON_ONCE(sk->sk_forward_alloc) from sk_stream_kill_queues(). · 8267b0d5

由 Kuniyuki Iwashima 提交于 6月 12, 2023

stable inclusion
from stable-v4.19.275
commit 9089260f9270abc99ef33ba2dc775ebcd9e534b2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9089260f9270abc99ef33ba2dc775ebcd9e534b2

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

commit 62ec33b4 upstream.

Christoph Paasch reported that commit b5fc2923 ("inet6: Remove
inet6_destroy_sock() in sk->sk_prot->destroy().") started triggering
WARN_ON_ONCE(sk->sk_forward_alloc) in sk_stream_kill_queues().  [0 - 2]
Also, we can reproduce it by a program in [3].

In the commit, we delay freeing ipv6_pinfo.pktoptions from sk->destroy()
to sk->sk_destruct(), so sk->sk_forward_alloc is no longer zero in
inet_csk_destroy_sock().

The same check has been in inet_sock_destruct() from at least v2.6,
we can just remove the WARN_ON_ONCE().  However, among the users of
sk_stream_kill_queues(), only CAIF is not calling inet_sock_destruct().
Thus, we add the same WARN_ON_ONCE() to caif_sock_destructor().

[0]: https://lore.kernel.org/netdev/39725AB4-88F1-41B3-B07F-949C5CAEFF4F@icloud.com/
[1]: https://github.com/multipath-tcp/mptcp_net-next/issues/341
[2]:
WARNING: CPU: 0 PID: 3232 at net/core/stream.c:212 sk_stream_kill_queues+0x2f9/0x3e0
Modules linked in:
CPU: 0 PID: 3232 Comm: syz-executor.0 Not tainted 6.2.0-rc5ab24eb4698afbe147b424149c529e2a43ec24eb5 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:sk_stream_kill_queues+0x2f9/0x3e0
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ec 00 00 00 8b ab 08 01 00 00 e9 60 ff ff ff e8 d0 5f b6 fe 0f 0b eb 97 e8 c7 5f b6 fe <0f> 0b eb a0 e8 be 5f b6 fe 0f 0b e9 6a fe ff ff e8 02 07 e3 fe e9
RSP: 0018:ffff88810570fc68 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888101f38f40 RSI: ffffffff8285e529 RDI: 0000000000000005
RBP: 0000000000000ce0 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000ce0 R11: 0000000000000001 R12: ffff8881009e9488
R13: ffffffff84af2cc0 R14: 0000000000000000 R15: ffff8881009e9458
FS:  00007f7fdfbd5800(0000) GS:ffff88811b600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32923000 CR3: 00000001062fc006 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 inet_csk_destroy_sock+0x1a1/0x320
 __tcp_close+0xab6/0xe90
 tcp_close+0x30/0xc0
 inet_release+0xe9/0x1f0
 inet6_release+0x4c/0x70
 __sock_release+0xd2/0x280
 sock_close+0x15/0x20
 __fput+0x252/0xa20
 task_work_run+0x169/0x250
 exit_to_user_mode_prepare+0x113/0x120
 syscall_exit_to_user_mode+0x1d/0x40
 do_syscall_64+0x48/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f7fdf7ae28d
Code: c1 20 00 00 75 10 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 37 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00000000007dfbb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f7fdf7ae28d
RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 0000000000000003
RBP: 0000000000000000 R08: 000000007f338e0f R09: 0000000000000e0f
R10: 000000007f338e13 R11: 0000000000000293 R12: 00007f7fdefff000
R13: 00007f7fdefffcd8 R14: 00007f7fdefffce0 R15: 00007f7fdefffcd8
 </TASK>

[3]: https://lore.kernel.org/netdev/20230208004245.83497-1-kuniyu@amazon.com/

Fixes: b5fc2923 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().")
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Reported-by: NChristoph Paasch <christophpaasch@icloud.com>
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

8267b0d5

dccp/tcp: Avoid negative sk_forward_alloc by ipv6_pinfo.pktoptions. · fe2eb442

由 Kuniyuki Iwashima 提交于 6月 12, 2023

stable inclusion
from stable-v4.19.273
commit 28a1742fcc1d8692e9090864373aa77fb3a0c8fd
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=28a1742fcc1d8692e9090864373aa77fb3a0c8fd

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

commit ca43ccf4 upstream.

Eric Dumazet pointed out [0] that when we call skb_set_owner_r()
for ipv6_pinfo.pktoptions, sk_rmem_schedule() has not been called,
resulting in a negative sk_forward_alloc.

We add a new helper which clones a skb and sets its owner only
when sk_rmem_schedule() succeeds.

Note that we move skb_set_owner_r() forward in (dccp|tcp)_v6_do_rcv()
because tcp_send_synack() can make sk_forward_alloc negative before
ipv6_opt_accepted() in the crossed SYN-ACK or self-connect() cases.

[0]: https://lore.kernel.org/netdev/CANn89iK9oc20Jdi_41jb9URdF210r7d1Y-+uypbMSbOfY6jqrg@mail.gmail.com/

Fixes: 323fbd0e ("net: dccp: Add handling of IPV6_PKTOPTIONS to dccp_v6_do_rcv()")
Fixes: 3df80d93 ("[DCCP]: Introduce DCCPv6")
Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

fe2eb442

media: dvb-core: Fix kernel WARNING for blocking operation in wait_event*() · cfbabcb3

由 Takashi Iwai 提交于 6月 12, 2023

mainline inclusion
from mainline-v6.4-rc3
commit b8c75e4a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6YKXB
CVE: CVE-2023-31084

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b8c75e4a1b325ea0a9433fa8834be97b5836b946

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

Using a semaphore in the wait_event*() condition is no good idea.
It hits a kernel WARN_ON() at prepare_to_wait_event() like:
  do not call blocking ops when !TASK_RUNNING; state=1 set at
  prepare_to_wait_event+0x6d/0x690

For avoiding the potential deadlock, rewrite to an open-coded loop
instead.  Unlike the loop in wait_event*(), this uses wait_woken()
after the condition check, hence the task state stays consistent.

CVE-2023-31084 was assigned to this bug.

Link: https://lore.kernel.org/r/CA+UBctCu7fXn4q41O_3=id1+OdyQ85tZY1x+TkT-6OVBL6KAUw@mail.gmail.com/

Link: https://lore.kernel.org/linux-media/20230512151800.1874-1-tiwai@suse.deReported-by: NYu Hao <yhao016@ucr.edu>
Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-31084Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

cfbabcb3

09 6月, 2023 2 次提交

sched: smart grid: init sched_grid_qos structure on QOS purpose · ce35ded5

由 Wang ShaoBo 提交于 6月 09, 2023

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQZ0
CVE: NA

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

As smart grid scheduling (SGS) may shrink resources and affect task QOS,
We provide methods for evaluating task QOS in divided grid, we mainly
focus on the following two aspects:

   1. Evaluate whether (such as CPU or memory) resources meet our demand
   2. Ensure the least impact when working with (cpufreq and cpuidle) governors

For tackling this questions, we have summarized several sampling methods
to obtain tasks' characteristics at same time reducing scheduling noise
as much as possible:

  1. we detected the key factors that how sensitive a process is in cpufreq
     or cpuidle adjustment, and to guide the cpufreq/cpuidle governor
  2. We dynamically monitor process memory bandwidth and adjust memory
     allocation to minimize cross-remote memory access
  3. We provide a variety of load tracking mechanisms to adapt to different
     types of task's load change

     ---------------------------------     -----------------
    |            class A              |   |     class B     |
    |    --------        --------     |   |     --------    |
    |   | group0 |      | group1 |    |---|    | group2 |   |----------+
    |    --------        --------     |   |     --------    |          |
    |    CPU/memory sensitive type    |   |   balance type  |          |
     ----------------+----------------     --------+--------           |
                     v                             v                   | (target cpufreq)
     -------------------------------------------------------           | (sensitivity)
    |              Not satisfied with QOS?                  |          |
     --------------------------+----------------------------           |
                               v                                       v
     -------------------------------------------------------     ----------------
    |              expand or shrink resource                |<--|  energy model  |
     ----------------------------+--------------------------     ----------------
                                 v                                     |
     -----------          -----------          ------------            v
    |           |        |           |        |            |     ---------------
    |   GRID0   +--------+   GRID1   +--------+   GRID2    |<-- |   governor    |
    |           |        |           |        |            |     ---------------
     -----------          -----------          ------------
                   \            |            /
                    \  -------------------  /
                      |  pages migration  |
                       -------------------

We will introduce the energy model in the follow-up implementation, and consider
the dynamic affinity adjustment between each divided grid in the runtime.
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

ce35ded5

sched: Introduce smart grid scheduling strategy for cfs · 713cfd26

由 Hui Tang 提交于 6月 09, 2023

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BQZ0
CVE: NA

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

We want to dynamically expand or shrink the affinity range of tasks
based on the CPU topology level while meeting the minimum resource
requirements of tasks.

We divide several level of affinity domains according to sched domains:

level4   * SOCKET  [                                                  ]
level3   * DIE     [                             ]
level2   * MC      [             ] [             ]
level1   * SMT     [     ] [     ] [     ] [     ]
level0   * CPU      0   1   2   3   4   5   6   7

Whether users tend to choose power saving or performance will affect
strategy of adjusting affinity, when selecting the power saving mode,
we will choose a more appropriate affinity based on the energy model
to reduce power consumption, while considering the QOS of resources
such as CPU and memory consumption, for instance, if the current task
CPU load is less than required, smart grid will judge whether to aggregate
tasks together into a smaller range or not according to energy model.

The main difference from EAS is that we pay more attention to the impact
of power consumption brought by such as cpuidle and DVFS, and classify
tasks to reduce interference and ensure resource QOS in each divided unit,
which are more suitable for general-purpose on non-heterogeneous CPUs.

        --------        --------        --------
       | group0 |      | group1 |      | group2 |
        --------        --------        --------
	   |                |              |
	   v                |              v
       ---------------------+-----     -----------------
      |                  ---v--   |   |
      |       DIE0      |  MC1 |  |   |   DIE1
      |                  ------   |   |
       ---------------------------     -----------------

We regularly count the resource satisfaction of groups, and adjust the
affinity, scheduling balance and migrating memory will be considered
based on memory location for better meetting resource requirements.
Signed-off-by: NHui Tang <tanghui20@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

713cfd26

08 6月, 2023 2 次提交

ipmi: fix SSIF not responding under certain cond. · aaf2ccb4

由 Zhang Yuchen 提交于 6月 08, 2023

stable inclusion
from stable-v4.19.283
commit ba810999356bffa4627985123c15327c692318e5
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BZ5U
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ba810999356bffa4627985123c15327c692318e5

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

[ Upstream commit 6d2555cd ]

The ipmi communication is not restored after a specific version of BMC is
upgraded on our server.
The ipmi driver does not respond after printing the following log:

    ipmi_ssif: Invalid response getting flags: 1c 1

I found that after entering this branch, ssif_info->ssif_state always
holds SSIF_GETTING_FLAGS and never return to IDLE.

As a result, the driver cannot be loaded, because the driver status is
checked during the unload process and must be IDLE in shutdown_ssif():

        while (ssif_info->ssif_state != SSIF_IDLE)
                schedule_timeout(1);

The process trigger this problem is:

1. One msg timeout and next msg start send, and call
ssif_set_need_watch().

2. ssif_set_need_watch()->watch_timeout()->start_flag_fetch() change
ssif_state to SSIF_GETTING_FLAGS.

3. In msg_done_handler() ssif_state == SSIF_GETTING_FLAGS, if an error
message is received, the second branch does not modify the ssif_state.

4. All retry action need IS_SSIF_IDLE() == True. Include retry action in
watch_timeout(), msg_done_handler(). Sending msg does not work either.
SSIF_IDLE is also checked in start_next_msg().

5. The only thing that can be triggered in the SSIF driver is
watch_timeout(), after destory_user(), this timer will stop too.

So, if enter this branch, the ssif_state will remain SSIF_GETTING_FLAGS
and can't send msg, no timer started, can't unload.

We did a comparative test before and after adding this patch, and the
result is effective.

Fixes: 25930707 ("ipmi: Add SMBus interface driver (SSIF)")

Cc: stable@vger.kernel.org
Signed-off-by: NZhang Yuchen <zhangyuchen.lcr@bytedance.com>
Message-Id: <20230412074907.80046-1-zhangyuchen.lcr@bytedance.com>
Signed-off-by: NCorey Minyard <minyard@acm.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYi Yang <yiyang13@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

aaf2ccb4

ipmi_ssif: Rename idle state and check · b0afa0fa

由 Corey Minyard 提交于 6月 08, 2023

stable inclusion
from stable-v4.19.283
commit 13b3a05b5b03b4fce5a9ea03dc91159dea1f6ef9
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7BZ5U
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=13b3a05b5b03b4fce5a9ea03dc91159dea1f6ef9

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

[ Upstream commit 8230831c ]

Rename the SSIF_IDLE() to IS_SSIF_IDLE(), since that is more clear, and
rename SSIF_NORMAL to SSIF_IDLE, since that's more accurate.

Cc: stable@vger.kernel.org
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Stable-dep-of: 6d2555cd ("ipmi: fix SSIF not responding under certain cond.")
Signed-off-by: NSasha Levin <sashal@kernel.org>

conflict:
	drivers/char/ipmi/ipmi_ssif.c
Signed-off-by: NYi Yang <yiyang13@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

b0afa0fa

openeuler / Kernel 1 年多 前同步成功

openeuler / Kernel
1 年多前同步成功