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
  • ----- 2026 -----
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • 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

  • 8 participants
  • 24008 discussions
[PATCH OLK-5.10] ALSA: timer: Fix UAF at snd_timer_user_params()
by Zhang Yuwei 02 Jul '26

02 Jul '26
From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.259 commit 92ad2d7f80cad43b046f093e808e11fe919d304a category: bugfix bugzilla: NA CVE: CVE-2026-53192 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng <kylebot(a)openai.com> Tested-by: Kyle Zeng <kylebot(a)openai.com> Cc: <stable(a)vger.kernel.org> Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index 708c9a46eefe..7b91c11241f5 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -1842,6 +1842,7 @@ static int snd_timer_user_params(struct file *file, struct snd_timer *t; int err; + guard(mutex)(&register_mutex); tu = file->private_data; if (!tu->timeri) return -EBADFD; -- 2.22.0
2 1
0 0
[PATCH OLK-6.6] ALSA: timer: Fix UAF at snd_timer_user_params()
by Zhang Yuwei 02 Jul '26

02 Jul '26
From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.259 commit 92ad2d7f80cad43b046f093e808e11fe919d304a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15878 CVE: CVE-2026-53192 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng <kylebot(a)openai.com> Tested-by: Kyle Zeng <kylebot(a)openai.com> Cc: <stable(a)vger.kernel.org> Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index 230babace502..e7cf47104257 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -1850,6 +1850,7 @@ static int snd_timer_user_params(struct file *file, struct snd_timer *t; int err; + guard(mutex)(&register_mutex); tu = file->private_data; if (!tu->timeri) return -EBADFD; -- 2.22.0
1 0
0 0
[PATCH OLK-5.10] ALSA: timer: Fix UAF at snd_timer_user_params()
by Zhang Yuwei 02 Jul '26

02 Jul '26
From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.259 commit 92ad2d7f80cad43b046f093e808e11fe919d304a category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng <kylebot(a)openai.com> Tested-by: Kyle Zeng <kylebot(a)openai.com> Cc: <stable(a)vger.kernel.org> Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index 708c9a46eefe..7b91c11241f5 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -1842,6 +1842,7 @@ static int snd_timer_user_params(struct file *file, struct snd_timer *t; int err; + guard(mutex)(&register_mutex); tu = file->private_data; if (!tu->timeri) return -EBADFD; -- 2.22.0
2 1
0 0
[PATCH OLK-5.10] ALSA: timer: Fix UAF at snd_timer_user_params()
by Zhang Yuwei 02 Jul '26

02 Jul '26
From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.259 commit 92ad2d7f80cad43b046f093e808e11fe919d304a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15878 CVE: CVE-2026-53192 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng <kylebot(a)openai.com> Tested-by: Kyle Zeng <kylebot(a)openai.com> Cc: <stable(a)vger.kernel.org> Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index 708c9a46eefe..7b91c11241f5 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -1842,6 +1842,7 @@ static int snd_timer_user_params(struct file *file, struct snd_timer *t; int err; + guard(mutex)(&register_mutex); tu = file->private_data; if (!tu->timeri) return -EBADFD; -- 2.22.0
1 0
0 0
[PATCH OLK-6.6] ALSA: timer: Fix UAF at snd_timer_user_params()
by Zhang Yuwei 02 Jul '26

02 Jul '26
From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.259 commit 92ad2d7f80cad43b046f093e808e11fe919d304a category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 053a401b592be424fea9d57c789f66cd5d8cec11 upstream. At releasing a timer object, e.g. when a userspace timer (CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it tries to detach the timer instances and release the resources. However, it's still possible that other in-flight tasks are holding the timer instance where the to-be-deleted timer object is associated, and this may lead to racy accesses. Fortunately, most of ioctls dealing with the timer instance list already have the protection with register_mutex, and this also avoids such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the concurrent ioctl may lead to use-after-free. This patch just adds the guard with register_mutex to protect snd_timer_user_params() for covering the code path as a quick workaround. It's no hot-path but rather a rarely issued ioctl, so the performance penalty doesn't matter. Reported-by: Kyle Zeng <kylebot(a)openai.com> Tested-by: Kyle Zeng <kylebot(a)openai.com> Cc: <stable(a)vger.kernel.org> Link: https://patch.msgid.link/20260606161145.1933447-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Yujun <linyujun809(a)h-partners.com> --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/core/timer.c b/sound/core/timer.c index 230babace502..e7cf47104257 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -1850,6 +1850,7 @@ static int snd_timer_user_params(struct file *file, struct snd_timer *t; int err; + guard(mutex)(&register_mutex); tu = file->private_data; if (!tu->timeri) return -EBADFD; -- 2.22.0
2 1
0 0
[PATCH OLK-6.6] cgroup/psi: Set of->priv to NULL upon file release
by Cai Xinchen 02 Jul '26

02 Jul '26
From: Chen Ridong <chenridong(a)huawei.com> mainline inclusion from mainline-v6.17-rc7 commit 94a4acfec14615e971eb2c9e1fa6c992c85ff6c6 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15693 CVE: CVE-2026-52991 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Setting of->priv to NULL when the file is released enables earlier bug detection. This allows potential bugs to manifest as NULL pointer dereferences rather than use-after-free errors[1], which are generally more difficult to diagnose. [1] https://lore.kernel.org/cgroups/38ef3ff9-b380-44f0-9315-8b3714b0948d@huawei… Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- kernel/cgroup/cgroup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 6949584610a5..7e08f494c61c 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -4215,6 +4215,7 @@ static void cgroup_file_release(struct kernfs_open_file *of) cft->release(of); put_cgroup_ns(ctx->ns); kfree(ctx); + of->priv = NULL; } static ssize_t cgroup_file_write(struct kernfs_open_file *of, char *buf, -- 2.18.0.huawei.25
2 1
0 0
[PATCH openEuler-1.0-LTS] RDMA/umem: Fix truncation for block sizes >= 4G
by Xia Fukun 01 Jul '26

01 Jul '26
From: Jason Gunthorpe <jgg(a)nvidia.com> mainline inclusion from mainline-v7.1 commit 15fe76e23615f502d051ef0768f86babaf08746c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15827 CVE: CVE-2026-53133 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses. Link: https://patch.msgid.link/r/1-v1-88303e9e509f+f7-ib_umem_types_jgg@nvidia.com Cc: stable(a)vger.kernel.org Fixes: a808273a495c ("RDMA/verbs: Add a DMA iterator to return aligned contiguous memory blocks") Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Conflicts: drivers/infiniband/core/iter.c drivers/infiniband/core/verbs.c [Newer versions moved this function to iter.c, this version adapts the changes in verbs.c.] Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/infiniband/core/verbs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c index 47a969a7f6f6..1b87b8d02cf9 100644 --- a/drivers/infiniband/core/verbs.c +++ b/drivers/infiniband/core/verbs.c @@ -2644,7 +2644,7 @@ EXPORT_SYMBOL(__rdma_block_iter_start); bool __rdma_block_iter_next(struct ib_block_iter *biter) { - unsigned int block_offset; + dma_addr_t block_offset; if (!biter->__sg_nents || !biter->__sg) return false; -- 2.34.1
2 1
0 0
[patch OLK-6.6] cgroup/psi: Set of->priv to NULL upon file release
by Cai Xinchen 01 Jul '26

01 Jul '26
From: Chen Ridong <chenridong(a)huawei.com> mainline inclusion from mainline-v6.17-rc7 commit 94a4acfec14615e971eb2c9e1fa6c992c85ff6c6 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15693 CVE: CVE-2026-52991 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Setting of->priv to NULL when the file is released enables earlier bug detection. This allows potential bugs to manifest as NULL pointer dereferences rather than use-after-free errors[1], which are generally more difficult to diagnose. [1] https://lore.kernel.org/cgroups/38ef3ff9-b380-44f0-9315-8b3714b0948d@huawei… Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- kernel/cgroup/cgroup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 6949584610a5..7e08f494c61c 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -4215,6 +4215,7 @@ static void cgroup_file_release(struct kernfs_open_file *of) cft->release(of); put_cgroup_ns(ctx->ns); kfree(ctx); + of->priv = NULL; } static ssize_t cgroup_file_write(struct kernfs_open_file *of, char *buf, -- 2.18.0.huawei.25
1 0
0 0
[PATCH openEuler-1.0-LTS] IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN
by Xia Fukun 01 Jul '26

01 Jul '26
From: Michael Bommarito <michael.bommarito(a)gmail.com> mainline inclusion from mainline-v7.1 commit 29e7b925ae6df64894e82ab6419994dc25580a8a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15861 CVE: CVE-2026-53176 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added. Fixes: b8d26b3be8b3 ("iser-target: Add iSCSI Extensions for RDMA (iSER) target driver") Link: https://patch.msgid.link/r/20260602194642.2273217-1-michael.bommarito@gmail… Cc: stable(a)vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito(a)gmail.com> Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Conflicts: drivers/infiniband/ulp/isert/ib_isert.c [Context differences, unrelated to the fix patch.] Signed-off-by: Xia Fukun <xiafukun(a)huawei.com> --- drivers/infiniband/ulp/isert/ib_isert.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c index f39670c5c25c..97119e8e0751 100644 --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -1473,6 +1473,12 @@ isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc) ib_dma_sync_single_for_cpu(ib_dev, isert_conn->login_req_dma, ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE); + if (unlikely(wc->byte_len < ISER_HEADERS_LEN)) { + isert_dbg("login request length %u is too short\n", + wc->byte_len); + return; + } + isert_conn->login_req_len = wc->byte_len - ISER_HEADERS_LEN; if (isert_conn->conn) { -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] ipc/shm: serialize orphan cleanup with shm_nattch updates
by Fanhua Li 01 Jul '26

01 Jul '26
From: Yilin Zhu <zylzyl2333(a)gmail.com> stable inclusion from stable-v5.10.259 commit b1e9aef48e4d8a0c1b54fb913077b0824ed7d650 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15634 CVE: CVE-2026-52930 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 2e5c6f4fd4001562781e99bbfc7f1f0127187542 upstream. shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal. Link: https://lore.kernel.org/9d97cc1031de2d0bace0edf3a668818aa2f4eca6.1777410234… Fixes: 4c677e2eefdb ("shm: optimize locking and ipc_namespace getting") Reported-by: Yuan Tan <yuantan098(a)gmail.com> Reported-by: Yifan Wu <yifanwucs(a)gmail.com> Reported-by: Juefei Pu <tomapufckgml(a)gmail.com> Reported-by: Xin Liu <bird(a)lzu.edu.cn> Signed-off-by: Yilin Zhu <zylzyl2333(a)gmail.com> Signed-off-by: Ren Wei <n05ec(a)lzu.edu.cn> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jeongjun Park <aha310510(a)gmail.com> Cc: Kees Cook <kees(a)kernel.org> Cc: Liam Howlett <liam(a)infradead.org> Cc: Lorenzo Stoakes <ljs(a)kernel.org> Cc: Serge Hallyn <sergeh(a)kernel.org> Cc: Vasiliy Kulikov <segoon(a)openwall.com> Cc: Davidlohr Bueso <dave(a)stgolabs.net> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: Serge Hallyn <serge(a)hallyn.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- ipc/shm.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/ipc/shm.c b/ipc/shm.c index bb017dd760f4d..25190965c9a50 100644 --- a/ipc/shm.c +++ b/ipc/shm.c @@ -415,15 +415,17 @@ static int shm_try_destroy_orphaned(int id, void *p, void *data) * We want to destroy segments without users and with already * exit'ed originating process. * - * As shp->* are changed under rwsem, it's safe to skip shp locking. + * shm_nattch can be changed under shm_perm.lock without holding the + * rwsem, so take the object lock before checking shm_may_destroy(). */ if (!list_empty(&shp->shm_clist)) return 0; - if (shm_may_destroy(shp)) { - shm_lock_by_ptr(shp); + shm_lock_by_ptr(shp); + if (shm_may_destroy(shp)) shm_destroy(ns, shp); - } + else + shm_unlock(shp); return 0; } -- 2.43.0
2 1
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • ...
  • 2401
  • Older →

HyperKitty Powered by HyperKitty