November 2024 - Kernel - mailweb.openeuler.org

[PATCH openEuler-22.03-LTS-SP1] drm/shmem-helper: Remove errant put in error path
by Qi Xi 01 Nov '24

01 Nov '24

From: Rob Clark <robdclark(a)chromium.org> mainline inclusion from mainline-v6.1 commit 24013314be6ee4ee456114a671e9fa3461323de8 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYRIR CVE: CVE-2022-48981 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free. Link: https://syzkaller.appspot.com/bug?extid=c8ae65286134dd1b800d Reported-by: syzbot+c8ae65286134dd1b800d(a)syzkaller.appspotmail.com Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects") Cc: stable(a)vger.kernel.org Signed-off-by: Rob Clark <robdclark(a)chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221130185748.357410-2-robdc… Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 8d1abf82d2b9..2688009df321 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -621,10 +621,8 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) shmem = to_drm_gem_shmem_obj(obj); ret = drm_gem_shmem_get_pages(shmem); - if (ret) { - drm_gem_vm_close(vma); + if (ret) return ret; - } vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND; vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); -- 2.33.0

2 1

[PATCH openEuler-22.03-LTS-SP1] Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()
by Qi Xi 01 Nov '24

01 Nov '24

From: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> mainline inclusion from mainline-v6.1-rc8 commit 8c9a59939deb4bfafdc451100c03d1e848b4169b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYRIY CVE: CVE-2022-48995 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed. Fixes: 3b384bd6c3f2 ("Input: raydium_ts_i2c - do not split tx transactions") Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5(a)huawei.com> Link: https://lore.kernel.org/r/20221202103412.2120169-1-zhangxiaoxu5@huawei.com Cc: stable(a)vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- drivers/input/touchscreen/raydium_i2c_ts.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c b/drivers/input/touchscreen/raydium_i2c_ts.c index 3a4952935366..3d9c5758d8a4 100644 --- a/drivers/input/touchscreen/raydium_i2c_ts.c +++ b/drivers/input/touchscreen/raydium_i2c_ts.c @@ -211,12 +211,14 @@ static int raydium_i2c_send(struct i2c_client *client, error = raydium_i2c_xfer(client, addr, xfer, ARRAY_SIZE(xfer)); if (likely(!error)) - return 0; + goto out; msleep(RM_RETRY_DELAY_MS); } while (++tries < RM_MAX_RETRIES); dev_err(&client->dev, "%s failed: %d\n", __func__, error); +out: + kfree(tx_buf); return error; } -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer
by Jinjiang Tu 01 Nov '24

01 Nov '24

From: Philip Yang <Philip.Yang(a)amd.com> mainline inclusion from mainline-v6.12-rc1 commit c86ad39140bbcb9dc75a10046c2221f657e8083b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRB0 CVE: CVE-2024-49991 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug. Signed-off-by: Philip Yang <Philip.Yang(a)amd.com> Reviewed-by: Felix Kuehling <felix.kuehling(a)amd.com> Acked-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Conflicts: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h drivers/gpu/drm/amd/amdkfd/kfd_chardev.c drivers/gpu/drm/amd/amdkfd/kfd_device.c drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c drivers/gpu/drm/amd/amdkfd/kfd_process.c drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c [conflicts due to 5b87245faf57 ("drm/amdkfd: Simplify kfd2kgd interface") isn't merged, and several calls aren't introduced.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 14 +++++++------- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 2 +- drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c index 79bd8bd97fae..b0a7c3403f02 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c @@ -342,15 +342,15 @@ int alloc_gtt_mem(struct kgd_dev *kgd, size_t size, return r; } -void free_gtt_mem(struct kgd_dev *kgd, void *mem_obj) +void free_gtt_mem(struct kgd_dev *kgd, void **mem_obj) { - struct amdgpu_bo *bo = (struct amdgpu_bo *) mem_obj; + struct amdgpu_bo **bo = (struct amdgpu_bo **) mem_obj; - amdgpu_bo_reserve(bo, true); - amdgpu_bo_kunmap(bo); - amdgpu_bo_unpin(bo); - amdgpu_bo_unreserve(bo); - amdgpu_bo_unref(&(bo)); + amdgpu_bo_reserve(*bo, true); + amdgpu_bo_kunmap(*bo); + amdgpu_bo_unpin(*bo); + amdgpu_bo_unreserve(*bo); + amdgpu_bo_unref(bo); } void get_local_mem_info(struct kgd_dev *kgd, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h index cc9aeab5468c..b45a45efcfe9 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h @@ -137,7 +137,7 @@ void amdgpu_amdkfd_gpu_reset(struct kgd_dev *kgd); int alloc_gtt_mem(struct kgd_dev *kgd, size_t size, void **mem_obj, uint64_t *gpu_addr, void **cpu_ptr, bool mqd_gfx9); -void free_gtt_mem(struct kgd_dev *kgd, void *mem_obj); +void free_gtt_mem(struct kgd_dev *kgd, void **mem_obj); void get_local_mem_info(struct kgd_dev *kgd, struct kfd_local_mem_info *mem_info); uint64_t get_gpu_clock_counter(struct kgd_dev *kgd); diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c b/drivers/gpu/drm/amd/amdkfd/kfd_device.c index 9f2eb8cf744a..5777b3fff549 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c @@ -533,7 +533,7 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd, kfd_doorbell_error: kfd_gtt_sa_fini(kfd); kfd_gtt_sa_init_error: - kfd->kfd2kgd->free_gtt_mem(kfd->kgd, kfd->gtt_mem); + kfd->kfd2kgd->free_gtt_mem(kfd->kgd, &kfd->gtt_mem); dev_err(kfd_device, "device %x:%x NOT added due to errors\n", kfd->pdev->vendor, kfd->pdev->device); @@ -550,7 +550,7 @@ void kgd2kfd_device_exit(struct kfd_dev *kfd) kfd_topology_remove_device(kfd); kfd_doorbell_fini(kfd); kfd_gtt_sa_fini(kfd); - kfd->kfd2kgd->free_gtt_mem(kfd->kgd, kfd->gtt_mem); + kfd->kfd2kgd->free_gtt_mem(kfd->kgd, &kfd->gtt_mem); } kfree(kfd); diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c index 985bebde5a34..c1c43c2ea33f 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c @@ -253,7 +253,7 @@ static void uninit_mqd(struct mqd_manager *mm, void *mqd, struct kfd_dev *kfd = mm->dev; if (mqd_mem_obj->gtt_mem) { - kfd->kfd2kgd->free_gtt_mem(kfd->kgd, mqd_mem_obj->gtt_mem); + kfd->kfd2kgd->free_gtt_mem(kfd->kgd, &mqd_mem_obj->gtt_mem); kfree(mqd_mem_obj); } else { kfd_gtt_sa_free(mm->dev, mqd_mem_obj); diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h index 43b82e14007e..4be8627cc810 100644 --- a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h +++ b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h @@ -294,7 +294,7 @@ struct kfd2kgd_calls { void **mem_obj, uint64_t *gpu_addr, void **cpu_ptr, bool mqd_gfx9); - void (*free_gtt_mem)(struct kgd_dev *kgd, void *mem_obj); + void (*free_gtt_mem)(struct kgd_dev *kgd, void **mem_obj); void (*get_local_mem_info)(struct kgd_dev *kgd, struct kfd_local_mem_info *mem_info); -- 2.34.1

2 1

[PATCH OLK-5.10] hisilicon/hisi_hbmdev: prevent NULL pointer dereference when corrently
by Zhang Zekun 01 Nov '24

01 Nov '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IB18IH ------------------------------------------------ There could have race problem when concurrently online or offline the device. "adev->handler" could be set to NULL when calling hbmdev_check. Let's add lock to prevent the NULL pointer dereference. Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- drivers/soc/hisilicon/hisi_hbmdev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/soc/hisilicon/hisi_hbmdev.c b/drivers/soc/hisilicon/hisi_hbmdev.c index 4c7da1a0eb33..f09388a80009 100644 --- a/drivers/soc/hisilicon/hisi_hbmdev.c +++ b/drivers/soc/hisilicon/hisi_hbmdev.c @@ -85,9 +85,7 @@ static int hbmdev_check(struct acpi_device *adev, void *arg) if (!adev->handler) return 0; - acpi_scan_lock_acquire(); adev->handler->hotplug.demand_offline = true; - acpi_scan_lock_release(); } return 0; @@ -98,7 +96,9 @@ static int memdev_power_off(struct acpi_device *adev) acpi_handle handle = adev->handle; acpi_status status; + acpi_scan_lock_acquire(); acpi_dev_for_each_child(adev, hbmdev_check, NULL); + acpi_scan_lock_release(); status = acpi_evaluate_object(handle, "_OFF", NULL, NULL); if (ACPI_FAILURE(status)) { -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] iio: health: afe4403: Fix oob read in afe4403_read_raw
by Qi Xi 01 Nov '24

01 Nov '24

From: Wei Yongjun <weiyongjun1(a)huawei.com> mainline inclusion from mainline-v6.1-rc7 commit 58143c1ed5882c138a3cd2251a336fc8755f23d9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYRDV CVE: CVE-2022-49031 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw The array size of afe4403_channel_leds is less than channels, so access with chan->address cause OOB read in afe4403_read_raw. Fix it by moving access before use it. Fixes: b36e8257641a ("iio: health/afe440x: Use regmap fields") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: Andrew Davis <afd(a)ti.com> Link: https://lore.kernel.org/r/20221107151946.89260-1-weiyongjun@huaweicloud.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- drivers/iio/health/afe4403.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c index 3bb4028c5d74..df3bc5c3d378 100644 --- a/drivers/iio/health/afe4403.c +++ b/drivers/iio/health/afe4403.c @@ -245,14 +245,14 @@ static int afe4403_read_raw(struct iio_dev *indio_dev, int *val, int *val2, long mask) { struct afe4403_data *afe = iio_priv(indio_dev); - unsigned int reg = afe4403_channel_values[chan->address]; - unsigned int field = afe4403_channel_leds[chan->address]; + unsigned int reg, field; int ret; switch (chan->type) { case IIO_INTENSITY: switch (mask) { case IIO_CHAN_INFO_RAW: + reg = afe4403_channel_values[chan->address]; ret = afe4403_read(afe, reg, val); if (ret) return ret; @@ -262,6 +262,7 @@ static int afe4403_read_raw(struct iio_dev *indio_dev, case IIO_CURRENT: switch (mask) { case IIO_CHAN_INFO_RAW: + field = afe4403_channel_leds[chan->address]; ret = regmap_field_read(afe->fields[field], val); if (ret) return ret; -- 2.33.0

2 1

[PATCH openEuler-1.0-LTS] iio: health: afe4403: Fix oob read in afe4403_read_raw
by Qi Xi 01 Nov '24

01 Nov '24

From: Wei Yongjun <weiyongjun1(a)huawei.com> mainline inclusion from mainline-v6.1-rc7 commit 58143c1ed5882c138a3cd2251a336fc8755f23d9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYRDV CVE: CVE-2022-49031 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw The array size of afe4403_channel_leds is less than channels, so access with chan->address cause OOB read in afe4403_read_raw. Fix it by moving access before use it. Fixes: b36e8257641a ("iio: health/afe440x: Use regmap fields") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Acked-by: Andrew Davis <afd(a)ti.com> Link: https://lore.kernel.org/r/20221107151946.89260-1-weiyongjun@huaweicloud.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- drivers/iio/health/afe4403.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c index 3bb4028c5d74..df3bc5c3d378 100644 --- a/drivers/iio/health/afe4403.c +++ b/drivers/iio/health/afe4403.c @@ -245,14 +245,14 @@ static int afe4403_read_raw(struct iio_dev *indio_dev, int *val, int *val2, long mask) { struct afe4403_data *afe = iio_priv(indio_dev); - unsigned int reg = afe4403_channel_values[chan->address]; - unsigned int field = afe4403_channel_leds[chan->address]; + unsigned int reg, field; int ret; switch (chan->type) { case IIO_INTENSITY: switch (mask) { case IIO_CHAN_INFO_RAW: + reg = afe4403_channel_values[chan->address]; ret = afe4403_read(afe, reg, val); if (ret) return ret; @@ -262,6 +262,7 @@ static int afe4403_read_raw(struct iio_dev *indio_dev, case IIO_CURRENT: switch (mask) { case IIO_CHAN_INFO_RAW: + field = afe4403_channel_leds[chan->address]; ret = regmap_field_read(afe->fields[field], val); if (ret) return ret; -- 2.33.0

2 2

[PATCH OLK-6.6 0/2] LoongArch: disable cpufreq driver
by Hongchen Zhang 01 Nov '24

01 Nov '24

Hongchen Zhang (1): LoongArch: disable cpufreq driver Ming Wang (1): cpufreq: loongson3-acpi: Initialize scaling_cur_freq correctly arch/loongarch/configs/loongson3_defconfig | 1 - drivers/cpufreq/loongson3-acpi-cpufreq.c | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) -- 2.33.0

2 4

[PATCH openEuler-22.03-LTS-SP1] efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption
by Qi Xi 01 Nov '24

01 Nov '24

From: Ard Biesheuvel <ardb(a)kernel.org> mainline inclusion from mainline-v6.12-rc1 commit 77d48d39e99170b528e4f2e9fc5d1d64cdedd386 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYQSJ CVE: CVE-2024-49858 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic. Cc: <stable(a)vger.kernel.org> Reported-by: Breno Leitao <leitao(a)debian.org> Tested-by: Usama Arif <usamaarif642(a)gmail.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Qi Xi <xiqi2(a)huawei.com> --- drivers/firmware/efi/libstub/tpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c index df3182f2e63a..1fd6823248ab 100644 --- a/drivers/firmware/efi/libstub/tpm.c +++ b/drivers/firmware/efi/libstub/tpm.c @@ -96,7 +96,7 @@ static void efi_retrieve_tcg2_eventlog(int version, efi_physical_addr_t log_loca } /* Allocate space for the logs and copy them. */ - status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, + status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY, sizeof(*log_tbl) + log_size, (void **)&log_tbl); if (status != EFI_SUCCESS) { -- 2.33.0

2 1

[PATCH openEuler-22.03-LTS-SP1] media: venus: fix use after free bug in venus_remove due to race condition
by Lin Ruifeng 01 Nov '24

01 Nov '24

From: Zheng Wang <zyytlz.wz(a)163.com> stable inclusion from stable-v5.10-227 commit c5a85ed88e043474161bbfe54002c89c1cb50ee2 bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCM CVE: CVE-2024-49981 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. Cc: stable(a)vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/media/platform/qcom/venus/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index 62d11c6e41d6..e4dce4e2b92f 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -354,6 +354,7 @@ static int venus_remove(struct platform_device *pdev) struct device *dev = core->dev; int ret; + cancel_delayed_work_sync(&core->work); ret = pm_runtime_get_sync(dev); WARN_ON(ret < 0); -- 2.17.1

2 1

[[PATCH OLK-6.6] 0/1] CVE-2024-49853
by 任敏敏(联通集团联通数字科技有限公司本部) 01 Nov '24

01 Nov '24

From: Ren MinMin <renmm6(a)chinaunicom.cn> CVE-2024-49853 Cristian Marussi (1): firmware: arm_scmi: Fix double free in OPTEE transport drivers/firmware/arm_scmi/optee.c | 7 +++++++ 1 file changed, 7 insertions(+) -- 2.43.0 Èç¹ûÄúŽíÎóœÓÊÕÁËžÃÓÊŒþ£¬ÇëÍš¹ýµç×ÓÓÊŒþÁ¢ŒŽÍšÖªÎÒÃÇ¡£Çë»ØžŽÓÊŒþµœ hqs-spmc@chinaunicom.cn£¬ŒŽ¿ÉÒÔÍË¶©ŽËÓÊŒþ¡£ÎÒÃÇœ«Á¢ŒŽœ«ÄúµÄÐÅÏ¢ŽÓÎÒÃÇµÄ·¢ËÍÄ¿ÂŒÖÐÉŸ³ý¡£ If you have received this email in error please notify us immediately by e-mail. Please reply to hqs-spmc(a)chinaunicom.cn ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

1 1

2024

2023

2022

2021

2020

2019

Kernel November 2024