mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 52 participants
  • 18285 discussions
[PATCH OLK-6.6] um: ubd: Do not use drvdata in release
by Yuan Can 31 Dec '24

31 Dec '24
From: Tiwei Bie <tiwei.btw(a)antgroup.com> stable inclusion from stable-v6.6.64 commit 2d194d951895df214e066d08146e77cb6e02c1d4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ CVE: CVE-2024-53184 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5bee35e5389f450a7eea7318deb9073e9414d3b1 upstream. The drvdata is not available in release. Let's just use container_of() to get the ubd instance. Otherwise, removing a ubd device will result in a crash: RIP: 0033:blk_mq_free_tag_set+0x1f/0xba RSP: 00000000e2083bf0 EFLAGS: 00010246 RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00 RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348 RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7 R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000 R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0 Kernel panic - not syncing: Segfault with no mm CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1 Workqueue: events mc_work_proc Stack: 00000000 604f7ef0 62c5d000 62405d20 e2083c30 6002c776 6002c755 600e47ff e2083c60 6025ffe3 04208060 603d36e0 Call Trace: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? kfree+0x0/0x100 [<6025ffe3>] device_release+0x70/0xba [<60381d6a>] kobject_put+0xb5/0xe2 [<6026027b>] put_device+0x19/0x1c [<6026a036>] platform_device_put+0x26/0x29 [<6026ac5a>] platform_device_unregister+0x2c/0x2e [<6002c52e>] ubd_remove+0xb8/0xd6 [<6002bb74>] ? mconsole_reply+0x0/0x50 [<6002b926>] mconsole_remove+0x160/0x1cc [<6002bbbc>] ? mconsole_reply+0x48/0x50 [<6003379c>] ? um_set_signals+0x3b/0x43 [<60061c55>] ? update_min_vruntime+0x14/0x70 [<6006251f>] ? dequeue_task_fair+0x164/0x235 [<600620aa>] ? update_cfs_group+0x0/0x40 [<603a0e77>] ? __schedule+0x0/0x3ed [<60033761>] ? um_set_signals+0x0/0x43 [<6002af6a>] mc_work_proc+0x77/0x91 [<600520b4>] process_scheduled_works+0x1af/0x2c3 [<6004ede3>] ? assign_work+0x0/0x58 [<600527a1>] worker_thread+0x2f7/0x37a [<6004ee3b>] ? set_pf_worker+0x0/0x64 [<6005765d>] ? arch_local_irq_save+0x0/0x2d [<60058e07>] ? kthread_exit+0x0/0x3a [<600524aa>] ? worker_thread+0x0/0x37a [<60058f9f>] kthread+0x130/0x135 [<6002068e>] new_thread_handler+0x85/0xb6 Cc: stable(a)vger.kernel.org Signed-off-by: Tiwei Bie <tiwei.btw(a)antgroup.com> Acked-By: Anton Ivanov <anton.ivanov(a)cambridgegreys.com> Link: https://patch.msgid.link/20241104163203.435515-3-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yuan Can <yuancan(a)huawei.com> --- arch/um/drivers/ubd_kern.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c index ef7b4b911a45..7ddda2c0ae43 100644 --- a/arch/um/drivers/ubd_kern.c +++ b/arch/um/drivers/ubd_kern.c @@ -799,7 +799,7 @@ static int ubd_open_dev(struct ubd *ubd_dev) static void ubd_device_release(struct device *dev) { - struct ubd *ubd_dev = dev_get_drvdata(dev); + struct ubd *ubd_dev = container_of(dev, struct ubd, pdev.dev); blk_mq_free_tag_set(&ubd_dev->tag_set); *ubd_dev = ((struct ubd) DEFAULT_UBD); -- 2.22.0
2 5
0 0
[PATCH openEuler-1.0-LTS] media: wl128x: Fix atomicity violation in fmc_send_cmd()
by dinglongwei 31 Dec '24

31 Dec '24
From: Qiu-ji Chen <chenqiuji666(a)gmail.com> stable inclusion from stable-v4.19.325 commit d16109c9fdc1b8cea4fe63b42e06e926c3f68990 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDOW CVE: CVE-2024-56700 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream. Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Cc: stable(a)vger.kernel.org Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/radio/wl128x/fmdrv_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/radio/wl128x/fmdrv_common.c b/drivers/media/radio/wl128x/fmdrv_common.c index 1cf4019689a5..8b8453dab660 100644 --- a/drivers/media/radio/wl128x/fmdrv_common.c +++ b/drivers/media/radio/wl128x/fmdrv_common.c @@ -472,11 +472,12 @@ int fmc_send_cmd(struct fmdev *fmdev, u8 fm_op, u16 type, void *payload, jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000); return -ETIMEDOUT; } + spin_lock_irqsave(&fmdev->resp_skb_lock, flags); if (!fmdev->resp_skb) { + spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); fmerr("Response SKB is missing\n"); return -EFAULT; } - spin_lock_irqsave(&fmdev->resp_skb_lock, flags); skb = fmdev->resp_skb; fmdev->resp_skb = NULL; spin_unlock_irqrestore(&fmdev->resp_skb_lock, flags); -- 2.22.0
2 5
0 0
[PATCH OLK-6.6] ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
by Long Li 31 Dec '24

31 Dec '24
From: Jordy Zomer <jordyzomer(a)google.com> mainline inclusion from mainline-v6.10-rc2 commit fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAPD CVE: CVE-2024-56627 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. Cc: stable(a)vger.kernel.org # v5.15+ Reported-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/smb/server/smb2pdu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index a080f80256cb..8bb70efc7899 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -6653,6 +6653,10 @@ int smb2_read(struct ksmbd_work *work) } offset = le64_to_cpu(req->Offset); + if (offset < 0) { + err = -EINVAL; + goto out; + } length = le32_to_cpu(req->Length); mincount = le32_to_cpu(req->MinimumCount); -- 2.39.2
2 5
0 0
[PATCH openEuler-22.03-LTS-SP1] ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
by Long Li 31 Dec '24

31 Dec '24
From: Jordy Zomer <jordyzomer(a)google.com> mainline inclusion from mainline-v6.10-rc2 commit fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAPD CVE: CVE-2024-56627 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. Cc: stable(a)vger.kernel.org # v5.15+ Reported-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/smb2pdu.c fs/smb/server/smb2pdu.c [Conflicts due to ksmbd rename to smb/server] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index f104de64493b..b6194837028a 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -6319,6 +6319,10 @@ int smb2_read(struct ksmbd_work *work) } offset = le64_to_cpu(req->Offset); + if (offset < 0) { + err = -EINVAL; + goto out; + } length = le32_to_cpu(req->Length); mincount = le32_to_cpu(req->MinimumCount); -- 2.39.2
2 5
0 0
[PATCH OLK-5.10] ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read
by Long Li 31 Dec '24

31 Dec '24
From: Jordy Zomer <jordyzomer(a)google.com> mainline inclusion from mainline-v6.10-rc2 commit fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAPD CVE: CVE-2024-56627 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. Cc: stable(a)vger.kernel.org # v5.15+ Reported-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Jordy Zomer <jordyzomer(a)google.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/ksmbd/smb2pdu.c fs/smb/server/smb2pdu.c [Conflicts due to ksmbd rename to smb/server] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/ksmbd/smb2pdu.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index f104de64493b..b6194837028a 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -6319,6 +6319,10 @@ int smb2_read(struct ksmbd_work *work) } offset = le64_to_cpu(req->Offset); + if (offset < 0) { + err = -EINVAL; + goto out; + } length = le32_to_cpu(req->Length); mincount = le32_to_cpu(req->MinimumCount); -- 2.39.2
2 5
0 0
[openeuler:OLK-5.10 2610/2610] mm/vmscan.c:4737 get_swapcache_reclaim_num() warn: unsigned 'swapcache_watermark[0]' is never less than zero.
by kernel test robot 31 Dec '24

31 Dec '24
tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 2a9b96eb97cfd6f68e431cb614cb0b75b127d783 commit: abfd8691d951fb037506e1ee52ed39abee8430fa [2610/2610] etmem: add swapcache reclaim to etmem config: x86_64-randconfig-161-20241231 (https://download.01.org/0day-ci/archive/20241231/202412311538.MIuGFM8n-lkp@…) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202412311538.MIuGFM8n-lkp@intel.com/ smatch warnings: mm/vmscan.c:4737 get_swapcache_reclaim_num() warn: unsigned 'swapcache_watermark[0]' is never less than zero. vim +4737 mm/vmscan.c 4733 4734 static unsigned long get_swapcache_reclaim_num(unsigned long *swapcache_watermark) 4735 { 4736 return total_swapcache_pages() > > 4737 swapcache_watermark[ETMEM_SWAPCACHE_WMARK_LOW] ? 4738 (total_swapcache_pages() - swapcache_watermark[ETMEM_SWAPCACHE_WMARK_LOW]) : 0; 4739 } 4740 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-6.6 v2] drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()
by Ye Bin 31 Dec '24

31 Dec '24
From: Li Huafei <lihuafei1(a)huawei.com> stable inclusion from stable-v6.6.64 commit 237f2dbfa00576bb1aa8dc2dce403c64e53270e6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEGFJ CVE: CVE-2024-56752 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a2f599046c671d6b46d93aed95b37241ce4504cf ] When the call to gf100_grctx_generate() fails, unlock gr->fecs.mutex before returning the error. Fixes smatch warning: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns '&gr->fecs.mutex'. Fixes: ca081fff6ecc ("drm/nouveau/gr/gf100-: generate golden context during first object alloc") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Reviewed-by: Lyude Paul <lyude(a)redhat.com> Signed-off-by: Lyude Paul <lyude(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241026173844.2392679-1-lihu… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c index 3648868bb9fc..cd533d16b966 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c @@ -443,6 +443,7 @@ gf100_gr_chan_new(struct nvkm_gr *base, struct nvkm_chan *fifoch, ret = gf100_grctx_generate(gr, chan, fifoch->inst); if (ret) { nvkm_error(&base->engine.subdev, "failed to construct context\n"); + mutex_unlock(&gr->fecs.mutex); return ret; } } -- 2.34.1
2 5
0 0
[PATCH OLK-6.6 v2] EDAC/igen6: Avoid segmentation fault on module unload
by Ye Bin 31 Dec '24

31 Dec '24
From: Orange Kao <orange(a)aiven.io> stable inclusion from stable-v6.6.64 commit 830cabb61113d92a425dd3038ccedbdfb3c8d079 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEDPH CVE: CVE-2024-56708 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fefaae90398d38a1100ccd73b46ab55ff4610fba ] The segmentation fault happens because: During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci->pvt_info to NULL to avoid the double kfree. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219360 Signed-off-by: Orange Kao <orange(a)aiven.io> Signed-off-by: Tony Luck <tony.luck(a)intel.com> Link: https://lore.kernel.org/r/20241104124237.124109-2-orange@aiven.io Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Ye Bin <yebin10(a)huawei.com> --- drivers/edac/igen6_edac.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/edac/igen6_edac.c b/drivers/edac/igen6_edac.c index a0edb61a5a01..0b408299699a 100644 --- a/drivers/edac/igen6_edac.c +++ b/drivers/edac/igen6_edac.c @@ -1075,6 +1075,7 @@ static int igen6_register_mci(int mc, u64 mchbar, struct pci_dev *pdev) imc->mci = mci; return 0; fail3: + mci->pvt_info = NULL; kfree(mci->ctl_name); fail2: edac_mc_free(mci); @@ -1099,6 +1100,7 @@ static void igen6_unregister_mcis(void) edac_mc_del_mc(mci->pdev); kfree(mci->ctl_name); + mci->pvt_info = NULL; edac_mc_free(mci); iounmap(imc->window); } -- 2.34.1
2 5
0 0
[PATCH openEuler-1.0-LTS] sched/dynamic_affinity: Calculate cpu capacity in real time when realtime tasks are running on this cpu
by He Yujie 31 Dec '24

31 Dec '24
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEBAG -------------------------------- The task_rq selection of dynamic affinity use cpu capacity to determine select_cpus range. When realtime tasks are running on the cpu all the time, cfs tasks and the thread of softirq is suppressed, and the cpu capacity is not updated in time. As a result, the select_cpus range is always selected for preferred_cpus. then cfs task will never be able to run because realtime tasks has been running. Therefore, if realtime tasks is running during the task_rq selection of dynamic affinity, the cpu capacity should be calculated to solve such a problem. Fixes: 70a232a564cf ("sched: Adjust wakeup cpu range according CPU util dynamicly") Signed-off-by: He Yujie <coka.heyujie(a)huawei.com> --- kernel/sched/fair.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 63f4344ac344..4a357dce540c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7226,6 +7226,19 @@ static inline bool prefer_cpus_valid(struct task_struct *p) cpumask_subset(prefer_cpus, &p->cpus_allowed); } +static unsigned long scale_rt_capacity(struct sched_domain *sd, int cpu); + +static inline unsigned long calc_cpu_capacity(int cpu) +{ + unsigned long capacity; + + capacity = scale_rt_capacity(NULL, cpu); + if (!capacity) + capacity = 1; + + return capacity; +} + /* * set_task_select_cpus: select the cpu range for task * @p: the task whose available cpu range will to set @@ -7288,7 +7301,11 @@ static void set_task_select_cpus(struct task_struct *p, int *idlest_cpu, } util_avg_sum += tg->se[cpu]->avg.util_avg; - tg_capacity += capacity_of(cpu); + + if (cpu_rq(cpu)->rt.rt_nr_running) + tg_capacity += calc_cpu_capacity(cpu); + else + tg_capacity += capacity_of(cpu); } rcu_read_unlock(); -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS] [Backport] ALSA: 6fire: Release resources at card release
by Lin Ruifeng 31 Dec '24

31 Dec '24
From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v4.19.325 commit 74357d0b5cd3ef544752bc9f21cbeee4902fae6c bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBEAEC CVE: CVE-2024-53239 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a0810c3d6dd2d29a9b92604d682eacd2902ce947 ] The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Link: https://patch.msgid.link/20241113111042.15058-6-tiwai@suse.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- sound/usb/6fire/chip.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/usb/6fire/chip.c b/sound/usb/6fire/chip.c index 17d5e3ee6d73..f5a9b7a0b585 100644 --- a/sound/usb/6fire/chip.c +++ b/sound/usb/6fire/chip.c @@ -66,8 +66,10 @@ static void usb6fire_chip_abort(struct sfire_chip *chip) } } -static void usb6fire_chip_destroy(struct sfire_chip *chip) +static void usb6fire_card_free(struct snd_card *card) { + struct sfire_chip *chip = card->private_data; + if (chip) { if (chip->pcm) usb6fire_pcm_destroy(chip); @@ -77,8 +79,6 @@ static void usb6fire_chip_destroy(struct sfire_chip *chip) usb6fire_comm_destroy(chip); if (chip->control) usb6fire_control_destroy(chip); - if (chip->card) - snd_card_free(chip->card); } } @@ -141,6 +141,7 @@ static int usb6fire_chip_probe(struct usb_interface *intf, chip->regidx = regidx; chip->intf_count = 1; chip->card = card; + card->private_free = usb6fire_card_free; ret = usb6fire_comm_init(chip); if (ret < 0) @@ -167,7 +168,7 @@ static int usb6fire_chip_probe(struct usb_interface *intf, return 0; destroy_chip: - usb6fire_chip_destroy(chip); + snd_card_free(card); return ret; } @@ -186,7 +187,6 @@ static void usb6fire_chip_disconnect(struct usb_interface *intf) chip->shutdown = true; usb6fire_chip_abort(chip); - usb6fire_chip_destroy(chip); } } } -- 2.22.0
2 1
0 0
  • ← Newer
  • 1
  • ...
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • ...
  • 1829
  • Older →

HyperKitty Powered by HyperKitty