- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] [Backport] RDMA/erdma: Hold QP references for AE and CM processing
by Tang Hui 24 Sep '26

24 Sep '26

From: Cheng Xu <chengyou(a)linux.alibaba.com> mainline inclusion from mainline-v7.3-rc1 commit a52eeff32024f190b3bdc99088c7becccd4fa60b category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/19471 CVE: CVE-2026-90308 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight. Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users. Fixes: 155055771704 ("RDMA/erdma: Add verbs implementation") Signed-off-by: Cheng Xu <chengyou(a)linux.alibaba.com> Link: https://patch.msgid.link/20260730124357.12976-2-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/hw/erdma/erdma_verbs.c [In erdma_destroy_qp() the downstream tree keeps its own local declaration order (struct erdma_qp_attrs qp_attrs plus a later struct erdma_cmdq_destroy_qp_req req) and its own internal modify-qp helper, so the only adaptation is adding the new unsigned long flags declaration; the xa_erase change is applied unchanged.] Co-authored-by: BackportAgent(a)deepseek-v4.1-flash Signed-off-by: Hulk Robot <hulkrobot(a)huawei.com> Signed-off-by: Tang Hui <tanghui20(a)huawei.com> --- drivers/infiniband/hw/erdma/erdma_cm.c | 6 ++---- drivers/infiniband/hw/erdma/erdma_eq.c | 3 ++- drivers/infiniband/hw/erdma/erdma_verbs.c | 6 +++++- drivers/infiniband/hw/erdma/erdma_verbs.h | 15 +++++++++++++++ 4 files changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/erdma/erdma_cm.c b/drivers/infiniband/hw/erdma/erdma_cm.c index e349e8d2fb50a..c747f77c1bdbd 100644 --- a/drivers/infiniband/hw/erdma/erdma_cm.c +++ b/drivers/infiniband/hw/erdma/erdma_cm.c @@ -1017,10 +1017,9 @@ int erdma_connect(struct iw_cm_id *id, struct iw_cm_conn_param *params) if (laddr->sa_family != AF_INET || raddr->sa_family != AF_INET) return -EAFNOSUPPORT; - qp = find_qp_by_qpn(dev, params->qpn); + qp = erdma_qp_get_by_qpn(dev, params->qpn); if (!qp) return -ENOENT; - erdma_qp_get(qp); ret = sock_create(AF_INET, SOCK_STREAM, IPPROTO_TCP, &s); if (ret < 0) @@ -1149,10 +1148,9 @@ int erdma_accept(struct iw_cm_id *id, struct iw_cm_conn_param *params) return -ECONNRESET; } - qp = find_qp_by_qpn(dev, params->qpn); + qp = erdma_qp_get_by_qpn(dev, params->qpn); if (!qp) return -ENOENT; - erdma_qp_get(qp); down_write(&qp->state_lock); if (qp->attrs.state > ERDMA_QP_STATE_RTR) { diff --git a/drivers/infiniband/hw/erdma/erdma_eq.c b/drivers/infiniband/hw/erdma/erdma_eq.c index d59e2de4e4e10..eb695f10ea395 100644 --- a/drivers/infiniband/hw/erdma/erdma_eq.c +++ b/drivers/infiniband/hw/erdma/erdma_eq.c @@ -65,7 +65,7 @@ void erdma_aeq_event_handler(struct erdma_dev *dev) erdma_cq_put(cq); } else { qpn = le32_to_cpu(aeqe->event_data0); - qp = find_qp_by_qpn(dev, qpn); + qp = erdma_qp_get_by_qpn(dev, qpn); if (!qp) continue; @@ -75,6 +75,7 @@ void erdma_aeq_event_handler(struct erdma_dev *dev) if (qp->ibqp.event_handler) qp->ibqp.event_handler(&event, qp->ibqp.qp_context); + erdma_qp_put(qp); } } diff --git a/drivers/infiniband/hw/erdma/erdma_verbs.c b/drivers/infiniband/hw/erdma/erdma_verbs.c index 0c66d2bed569b..8aa830aee88bd 100644 --- a/drivers/infiniband/hw/erdma/erdma_verbs.c +++ b/drivers/infiniband/hw/erdma/erdma_verbs.c @@ -1266,6 +1266,7 @@ int erdma_destroy_qp(struct ib_qp *ibqp, struct ib_udata *udata) struct erdma_ucontext *ctx = rdma_udata_to_drv_context( udata, struct erdma_ucontext, ibucontext); struct erdma_qp_attrs qp_attrs; + unsigned long flags; int err; struct erdma_cmdq_destroy_qp_req req; @@ -1284,6 +1285,10 @@ int erdma_destroy_qp(struct ib_qp *ibqp, struct ib_udata *udata) if (err) return err; + xa_lock_irqsave(&dev->qp_xa, flags); + __xa_erase(&dev->qp_xa, QP_ID(qp)); + xa_unlock_irqrestore(&dev->qp_xa, flags); + erdma_qp_put(qp); wait_for_completion(&qp->safe_free); @@ -1306,7 +1311,6 @@ int erdma_destroy_qp(struct ib_qp *ibqp, struct ib_udata *udata) if (qp->cep) erdma_cep_put(qp->cep); - xa_erase(&dev->qp_xa, QP_ID(qp)); return 0; } diff --git a/drivers/infiniband/hw/erdma/erdma_verbs.h b/drivers/infiniband/hw/erdma/erdma_verbs.h index 10b9b8a5f6a8b..687017531b958 100644 --- a/drivers/infiniband/hw/erdma/erdma_verbs.h +++ b/drivers/infiniband/hw/erdma/erdma_verbs.h @@ -280,6 +280,21 @@ static inline struct erdma_qp *find_qp_by_qpn(struct erdma_dev *dev, int id) return (struct erdma_qp *)xa_load(&dev->qp_xa, id); } +static inline struct erdma_qp *erdma_qp_get_by_qpn(struct erdma_dev *dev, + int id) +{ + struct erdma_qp *qp; + unsigned long flags; + + xa_lock_irqsave(&dev->qp_xa, flags); + qp = xa_load(&dev->qp_xa, id); + if (qp && !kref_get_unless_zero(&qp->ref)) + qp = NULL; + xa_unlock_irqrestore(&dev->qp_xa, flags); + + return qp; +} + static inline struct erdma_cq *erdma_cq_get_by_cqn(struct erdma_dev *dev, int id) { -- 2.34.1

2 1

[PATCH OLK-5.10] NFSD: check truncate permission under inode lock
by Yang Erkun 24 Sep '26

24 Sep '26

From: Chuck Lever <chuck.lever(a)oracle.com> mainline inclusion from mainline-v7.3-rc1 commit b778e0e0a16759f22a70579c3cf8d254a40d4a7f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18761 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change(). This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), so NFSD must make this decision against the locked size it is about to change. Split the write-count acquisition from the truncation permission check. Keep get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load. Fixes: 783112f7401f ("nfsd: special case truncates some more") Cc: stable(a)vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason <clm(a)meta.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-6-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/vfs.c [v5.10 has no fh_fill_pre_attrs()/inode_lock() in nfsd_setattr(), so keep fh_lock() with the existing size_attr and place the nfsd_may_truncate() check inside that locked block. Keep @iap in nfsd_get_write_access() to retain the v5.10 locks_verify_truncate() call, and return the __be32 permission error from out_unlock by making err take precedence.] Signed-off-by: Yang Erkun <yangerkun(a)huawei.com> --- fs/nfsd/vfs.c | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index 7820945e2d07..bac671ac36dd 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -329,20 +329,23 @@ nfsd_sanitize_attrs(struct inode *inode, struct iattr *iap) } static __be32 -nfsd_get_write_access(struct svc_rqst *rqstp, struct svc_fh *fhp, - struct iattr *iap) +nfsd_may_truncate(struct svc_rqst *rqstp, struct svc_fh *fhp, + struct iattr *iap) { struct inode *inode = d_inode(fhp->fh_dentry); - int host_err; - if (iap->ia_size < inode->i_size) { - __be32 err; + if (iap->ia_size >= i_size_read(inode)) + return nfs_ok; - err = nfsd_permission(rqstp, fhp->fh_export, fhp->fh_dentry, - NFSD_MAY_TRUNC | NFSD_MAY_OWNER_OVERRIDE); - if (err) - return err; - } + return nfsd_permission(rqstp, fhp->fh_export, fhp->fh_dentry, + NFSD_MAY_TRUNC | NFSD_MAY_OWNER_OVERRIDE); +} + +static __be32 +nfsd_get_write_access(struct svc_fh *fhp, struct iattr *iap) +{ + struct inode *inode = d_inode(fhp->fh_dentry); + int host_err; host_err = get_write_access(inode); if (host_err) @@ -429,7 +432,7 @@ nfsd_setattr(struct svc_rqst *rqstp, struct svc_fh *fhp, struct iattr *iap, * setattr call. */ if (size_change) { - err = nfsd_get_write_access(rqstp, fhp, iap); + err = nfsd_get_write_access(fhp, iap); if (err) return err; } @@ -452,6 +455,10 @@ nfsd_setattr(struct svc_rqst *rqstp, struct svc_fh *fhp, struct iattr *iap, if (iap->ia_size < 0) goto out_unlock; + err = nfsd_may_truncate(rqstp, fhp, iap); + if (err) + goto out_unlock; + host_err = notify_change(dentry, &size_attr, NULL); if (host_err) goto out_unlock; @@ -476,7 +483,7 @@ nfsd_setattr(struct svc_rqst *rqstp, struct svc_fh *fhp, struct iattr *iap, out: if (!host_err) host_err = commit_metadata(fhp); - return nfserrno(host_err); + return err ? err : nfserrno(host_err); } #if defined(CONFIG_NFSD_V4) -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] NFSD: check truncate permission under inode lock
by Yang Erkun 24 Sep '26

24 Sep '26

From: Chuck Lever <chuck.lever(a)oracle.com> mainline inclusion from mainline-v7.3-rc1 commit b778e0e0a16759f22a70579c3cf8d254a40d4a7f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18761 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change(). This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), so NFSD must make this decision against the locked size it is about to change. Split the write-count acquisition from the truncation permission check. Keep get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load. Fixes: 783112f7401f ("nfsd: special case truncates some more") Cc: stable(a)vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason <clm(a)meta.com> Signed-off-by: Jeff Layton <jlayton(a)kernel.org> Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-6-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Conflicts: fs/nfsd/vfs.c [v4.19 has no fh_fill_pre_attrs()/inode_lock() in nfsd_setattr(), so keep fh_lock() with the existing size_attr and place the nfsd_may_truncate() check inside that locked block. Keep @iap in nfsd_get_write_access() to retain the v4.19 locks_verify_truncate() call, and return the __be32 permission error from out_unlock by making err take precedence.] Signed-off-by: Yang Erkun <yangerkun(a)huawei.com> --- fs/nfsd/vfs.c | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c index a500bb9e2315..eb4833b69f21 100644 --- a/fs/nfsd/vfs.c +++ b/fs/nfsd/vfs.c @@ -356,20 +356,23 @@ nfsd_sanitize_attrs(struct inode *inode, struct iattr *iap) } static __be32 -nfsd_get_write_access(struct svc_rqst *rqstp, struct svc_fh *fhp, - struct iattr *iap) +nfsd_may_truncate(struct svc_rqst *rqstp, struct svc_fh *fhp, + struct iattr *iap) { struct inode *inode = d_inode(fhp->fh_dentry); - int host_err; - if (iap->ia_size < inode->i_size) { - __be32 err; + if (iap->ia_size >= i_size_read(inode)) + return nfs_ok; - err = nfsd_permission(rqstp, fhp->fh_export, fhp->fh_dentry, - NFSD_MAY_TRUNC | NFSD_MAY_OWNER_OVERRIDE); - if (err) - return err; - } + return nfsd_permission(rqstp, fhp->fh_export, fhp->fh_dentry, + NFSD_MAY_TRUNC | NFSD_MAY_OWNER_OVERRIDE); +} + +static __be32 +nfsd_get_write_access(struct svc_fh *fhp, struct iattr *iap) +{ + struct inode *inode = d_inode(fhp->fh_dentry); + int host_err; host_err = get_write_access(inode); if (host_err) @@ -456,7 +459,7 @@ nfsd_setattr(struct svc_rqst *rqstp, struct svc_fh *fhp, struct iattr *iap, * setattr call. */ if (size_change) { - err = nfsd_get_write_access(rqstp, fhp, iap); + err = nfsd_get_write_access(fhp, iap); if (err) return err; } @@ -479,6 +482,10 @@ nfsd_setattr(struct svc_rqst *rqstp, struct svc_fh *fhp, struct iattr *iap, if (iap->ia_size < 0) goto out_unlock; + err = nfsd_may_truncate(rqstp, fhp, iap); + if (err) + goto out_unlock; + host_err = notify_change(dentry, &size_attr, NULL); if (host_err) goto out_unlock; @@ -503,7 +510,7 @@ nfsd_setattr(struct svc_rqst *rqstp, struct svc_fh *fhp, struct iattr *iap, out: if (!host_err) host_err = commit_metadata(fhp); - return nfserrno(host_err); + return err ? err : nfserrno(host_err); } #if defined(CONFIG_NFSD_V4) -- 2.52.0

2 1

[PATCH OLK-5.10 V1] HID: sensor-hub: Fix out-of-bounds write in sensor_hub_get_feature
by Yao Yiqi 24 Sep '26

24 Sep '26

From: Xingrui Li <baka9(a)bakabaka9.tech> stable inclusion from stable-v5.10.270 commit 1c0463f0f028801a933f090cd2695f132635b374 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/18767 CVE: CVE-2026-89729 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit c92693f3ed099401d0383ef35ca1fe1e6ba033de upstream. sensor_hub_get_feature() clamps its return value to the caller's buffer size, but the copy loop still copies field->report_size / 8 bytes for each report value. A malicious HID descriptor can advertise a large feature field size while an IIO caller supplies a small stack buffer, such as a single s32, causing an out-of-bounds write. HID core stores parsed report values in __s32 slots and clamps extracted values to 32 bits. Reject feature fields that require more than one slot per value, guard the total byte count calculation, and clamp each per-value copy to the remaining caller buffer. Fixes: 5459ada2b3cd69 ("HID: sensor-hub: Fix packing of result buffer for feature report") Cc: stable(a)kernel.org Assisted-by: OpenAI:GPT-5.5-Cyber Signed-off-by: Xingrui Li <baka9(a)bakabaka9.tech> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yao Yiqi <yaoyiqi3(a)huawei.com> --- drivers/hid/hid-sensor-hub.c | 42 +++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 17 deletions(-) diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c index f9983145d4e7..5b72b453191c 100644 --- a/drivers/hid/hid-sensor-hub.c +++ b/drivers/hid/hid-sensor-hub.c @@ -240,12 +240,17 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id, u32 field_index, int buffer_size, void *buffer) { struct hid_report *report; + struct hid_field *field; struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev); - int report_size; + size_t field_size; + size_t report_size; + size_t copied = 0; + size_t to_copy; int ret = 0; - u8 *val_ptr; - int buffer_index = 0; - int i; + unsigned int i; + + if (!buffer || buffer_size <= 0) + return -EINVAL; memset(buffer, 0, buffer_size); @@ -259,26 +264,29 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id, hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT); hid_hw_wait(hsdev->hdev); + field = report->field[field_index]; + /* calculate number of bytes required to read this field */ - report_size = DIV_ROUND_UP(report->field[field_index]->report_size, - 8) * - report->field[field_index]->report_count; - if (!report_size) { + field_size = DIV_ROUND_UP(field->report_size, 8); + /* HID core stores each parsed report value in a __s32 slot. */ + if (!field_size || field_size > sizeof(field->value[0])) { + ret = -EINVAL; + goto done_proc; + } + if (field->report_count > SIZE_MAX / field_size) { ret = -EINVAL; goto done_proc; } - ret = min(report_size, buffer_size); - val_ptr = (u8 *)report->field[field_index]->value; - for (i = 0; i < report->field[field_index]->report_count; ++i) { - if (buffer_index >= ret) - break; + report_size = field_size * field->report_count; + report_size = min_t(size_t, report_size, buffer_size); - memcpy(&((u8 *)buffer)[buffer_index], val_ptr, - report->field[field_index]->report_size / 8); - val_ptr += sizeof(__s32); - buffer_index += (report->field[field_index]->report_size / 8); + for (i = 0; i < field->report_count && copied < report_size; ++i) { + to_copy = min(field_size, report_size - copied); + memcpy(&((u8 *)buffer)[copied], &field->value[i], to_copy); + copied += to_copy; } + ret = copied; done_proc: mutex_unlock(&data->mutex); -- 2.34.1

2 1

[PATCH OLK-6.6 0/2] cpufreq: devfreq uncore DVFS governor feature
by Lifeng Zheng 24 Sep '26

24 Sep '26

From: Hongye Lin <linhongye(a)h-partners.com> driver inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/9163 ---------------------------------------------------------------------- cpufreq: devfreq uncore DVFS governor feature Jie Zhan (2): perf/core: Add perf_pmu_type_by_parent_dev() for in-kernel PMU lookup devfreq: hisi: Add devfreq-event support via L3C PMU drivers/devfreq/Kconfig | 3 +- drivers/devfreq/hisi_uncore_freq.c | 444 ++++++++++++++++++++++++++++- include/linux/perf_event.h | 3 + kernel/events/core.c | 28 ++ 4 files changed, 474 insertions(+), 4 deletions(-) -- 2.33.0

2 3

[PATCH OLK-5.10 V1 0/5] Fix CVE-2026-90329
by Yao Yiqi 24 Sep '26

24 Sep '26

5 commits in total. PATCH 3 for CVE fix, PATCH 1 and 2 as stable dependencies, PATCH 4 and 5 as fix. Dan Carpenter (1): HID: fix an error code in hid_check_device_match() Dmitry Torokhov (2): HID: split apart hid_device_probe to make logic more apparent HID: ensure timely release of driver-allocated resources Vitaly Kuznetsov (1): HID: hyperv: streamline driver probe to avoid devres issues Yousef Alhouseen (1): HID: synchronize input before cleaning up a failed probe drivers/hid/hid-core.c | 120 ++++++++++++++++++++++++--------------- drivers/hid/hid-hyperv.c | 58 +++++++++++++------ include/linux/hid.h | 1 + 3 files changed, 115 insertions(+), 64 deletions(-) -- 2.34.1

2 6

[PATCH OLK-6.6] mm: fix bad page state in remap_try_huge_pmd() on non-empty PMD entry
by Jinjiang Tu 24 Sep '26

24 Sep '26

remap_try_huge_pmd() called pmd_free_pte_page() to free an existing PTE page table when the PMD entry was present. However, pmd_free_pte_page() uses the kernel page-table free path, which is not appropriate for user mappings. When the PMD entry is non-empty, this results in the underlying page being freed through the kernel page-table free path (__pmd_free_pte_page -> __free_pages -> free_unref_page), corrupting page state and triggering: BUG: Bad page state in process drv_hlt_dsmi_te pfn:809a2b04 page: refcount:0 mapcount:0 ... page_type: 0xfffffdff(table) page dumped because: nonzero mapcount Call trace: bad_page+0xa0/0x1f8 free_unref_page+0xb58/0x1050 __pmd_free_pte_page.part.0+0x10c/0x1f8 pmd_free_pte_page+0x4c/0x78 remap_try_huge_pmd+0x134/0x468 remap_pfn_range_internal+0x334/0x690 remap_pfn_range_try_pmd+0xb4/0x138 When the PMD entry is non-empty, fall back to 4K granularity mapping instead of attempting to free the page table. Rather than simply switching to the user page table free path, the original logic is dropped entirely because it assumes the PTE table is empty without actually checking. If a driver maps the same range repeatedly, the PTE table may still contain valid entries, and freeing it would silently destroy existing mappings without any error. Falling back to 4K granularity avoids both the wrong free path and the risk of silently corrupting existing mappings. Fixes: 923e224a1246 ("mm: introduce remap_pfn_range_try_pmd() for PMD-level hugepage mapping") --- mm/memory.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index f98116b7b23e..7fc3eebcf1ea 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2605,18 +2605,24 @@ static int remap_try_huge_pmd(struct mm_struct *mm, pmd_t *pmd, if (!IS_ALIGNED(pfn, HPAGE_PMD_NR)) return 0; - if (pmd_present(*pmd) && !pmd_free_pte_page(pmd, addr)) + if (!pmd_none(*pmd)) return 0; pgtable = pte_alloc_one(mm); if (unlikely(!pgtable)) return 0; - mm_inc_nr_ptes(mm); ptl = pmd_lock(mm, pmd); + if (!pmd_none(*pmd)) { + spin_unlock(ptl); + pte_free(mm, pgtable); + return 0; + } + set_pmd_at(mm, addr, pmd, pmd_mkspecial(pmd_mkhuge(pfn_pmd(pfn, prot)))); pgtable_trans_huge_deposit(mm, pmd, pgtable); spin_unlock(ptl); + mm_inc_nr_ptes(mm); return 1; } -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
by Jinjiang Tu 24 Sep '26

24 Sep '26

mainline inclusion from mainline-v7.3 commit b6ac0b3f6013c168f22cad97e79967accacb08e1 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/10048 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't visible, thread B reads a root that points to the old anon_vma and locks it. As a result, thread B can call anon_vma_lock_write() with the old root, and call anon_vma_unlock_write() with the new root, leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore (its count is dropped from 0 to -1 due to wrong unlock). To fix it, change the plain store `vma->anon_vma = anon_vma` to store release, so that the fields of anon_vma are visible before anon_vma is published to vma->anon_vma. At read side, the load of anon_vma and anon_vma->root have address dependency. According to Documentation/memory-barriers.txt and some investigations, only Alpha needs address-dependency barriers and it has been handled by READ_ONCE() in reusable_anon_vma(). We reproduced this issue in v5.10 with KSM enabled. The kernel doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking VMA merging for new VMAs"), so there are many adjacent VMAs that aren't merged but are compatible for anon_vma. Without this fix, our production environment could reproduce this issue about 2-5 times each month. After adding a smp_mb() before anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different to this patch, this issue hasn't been reproduced for one month. Link: https://lore.kernel.org/20260908122924.554373-1-tujinjiang@huawei.com Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs(a)kernel.org> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Harry Yoo <harry(a)kernel.org> Cc: Hiroyouki Kamezawa <kamezawa.hiroyu(a)jp.fujitsu.com> Cc: Jann Horn <jannh(a)google.com> Cc: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Larry Woodman <lwoodman(a)redhat.com> Cc: Liam R. Howlett <liam(a)infradead.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Conflicts: mm/rmap.c mm/mmap.c mm/vma.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/mmap.c | 7 +++++++ mm/rmap.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index ad643f9dd3a4..7b1e9c28a4cf 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1235,6 +1235,13 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * acceptable for merging, so we can do all of this optimistically. But * we do that READ_ONCE() to make sure that we never re-load the pointer. * + * The READ_ONCE() establishes an address dependency between anon_vma and + * any access to its fields, which pairs with the assignment to + * vma->anon_vma performed with release semantics in __anon_vma_prepare(). + * + * This is especially important as anon_vma's are SLAB_TYPESAFE_BY_RCU so + * accessing an uninitialised anon_vma's fields may result in a UAF. + * * IOW: that the "list_is_singular()" test on the anon_vma_chain only * matters for the 'stable anon_vma' case (ie the thing we want to avoid * is to return an anon_vma that is "complex" due to having gone through diff --git a/mm/rmap.c b/mm/rmap.c index e6724fd0617c..78ca23c32cb9 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -199,7 +199,11 @@ int __anon_vma_prepare(struct vm_area_struct *vma) /* page_table_lock to protect against threads */ spin_lock(&mm->page_table_lock); if (likely(!vma->anon_vma)) { - vma->anon_vma = anon_vma; + /* + * Make anon_vma fields visible before anon_vma is published. + * Paired with an address dependency in reusable_anon_vma(). + */ + smp_store_release(&vma->anon_vma, anon_vma); anon_vma_chain_link(vma, avc, anon_vma); anon_vma->num_active_vmas++; allocated = NULL; -- 2.43.0

2 1

[PATCH OLK-6.6] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
by Jinjiang Tu 24 Sep '26

24 Sep '26

mainline inclusion from mainline-v7.3 commit b6ac0b3f6013c168f22cad97e79967accacb08e1 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/10048 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't visible, thread B reads a root that points to the old anon_vma and locks it. As a result, thread B can call anon_vma_lock_write() with the old root, and call anon_vma_unlock_write() with the new root, leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore (its count is dropped from 0 to -1 due to wrong unlock). To fix it, change the plain store `vma->anon_vma = anon_vma` to store release, so that the fields of anon_vma are visible before anon_vma is published to vma->anon_vma. At read side, the load of anon_vma and anon_vma->root have address dependency. According to Documentation/memory-barriers.txt and some investigations, only Alpha needs address-dependency barriers and it has been handled by READ_ONCE() in reusable_anon_vma(). We reproduced this issue in v5.10 with KSM enabled. The kernel doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking VMA merging for new VMAs"), so there are many adjacent VMAs that aren't merged but are compatible for anon_vma. Without this fix, our production environment could reproduce this issue about 2-5 times each month. After adding a smp_mb() before anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different to this patch, this issue hasn't been reproduced for one month. Link: https://lore.kernel.org/20260908122924.554373-1-tujinjiang@huawei.com Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs(a)kernel.org> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Harry Yoo <harry(a)kernel.org> Cc: Hiroyouki Kamezawa <kamezawa.hiroyu(a)jp.fujitsu.com> Cc: Jann Horn <jannh(a)google.com> Cc: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Larry Woodman <lwoodman(a)redhat.com> Cc: Liam R. Howlett <liam(a)infradead.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Conflicts: mm/rmap.c mm/mmap.c mm/vma.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/mmap.c | 7 +++++++ mm/rmap.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index 669bc1b74b35..7b0ba4395441 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1170,6 +1170,13 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * acceptable for merging, so we can do all of this optimistically. But * we do that READ_ONCE() to make sure that we never re-load the pointer. * + * The READ_ONCE() establishes an address dependency between anon_vma and + * any access to its fields, which pairs with the assignment to + * vma->anon_vma performed with release semantics in __anon_vma_prepare(). + * + * This is especially important as anon_vma's are SLAB_TYPESAFE_BY_RCU so + * accessing an uninitialised anon_vma's fields may result in a UAF. + * * IOW: that the "list_is_singular()" test on the anon_vma_chain only * matters for the 'stable anon_vma' case (ie the thing we want to avoid * is to return an anon_vma that is "complex" due to having gone through diff --git a/mm/rmap.c b/mm/rmap.c index ad0213898dcd..12718f5ed9d2 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -210,7 +210,11 @@ int __anon_vma_prepare(struct vm_area_struct *vma) /* page_table_lock to protect against threads */ spin_lock(&mm->page_table_lock); if (likely(!vma->anon_vma)) { - vma->anon_vma = anon_vma; + /* + * Make anon_vma fields visible before anon_vma is published. + * Paired with an address dependency in reusable_anon_vma(). + */ + smp_store_release(&vma->anon_vma, anon_vma); anon_vma_chain_link(vma, avc, anon_vma); anon_vma->num_active_vmas++; allocated = NULL; -- 2.43.0

2 1

[PATCH OLK-5.10] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
by Jinjiang Tu 24 Sep '26

24 Sep '26

mainline inclusion from mainline-v7.3 commit b6ac0b3f6013c168f22cad97e79967accacb08e1 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/10048 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask. INFO: task main:2354726 blocked for more than 120 seconds. Tainted: G E 5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main state:D stack: 0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace: __switch_to+0x7c/0xbc __schedule+0x3b4/0x8a0 schedule+0x50/0xe0 rwsem_down_write_slowpath+0x3cc/0x6cc down_write+0x60/0x260 __anon_vma_prepare+0x6c/0x210 do_anonymous_page+0x258/0x660 handle_pte_fault+0x188/0x214 __handle_mm_fault+0x1b0/0x380 handle_mm_fault+0xf4/0x284 do_page_fault+0x19c/0x494 do_translation_fault+0xcc/0xf8 do_mem_abort+0x48/0xac el0_da+0x44/0x80 el0_sync_handler+0x88/0xb4 el0_sync+0x160/0x180 After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1. There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock. After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore. This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()). Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading. THREAD A THREAD B __anon_vma_prepare __anon_vma_prepare find_mergeable_anon_vma() -> NULL anon_vma = anon_vma_alloc(); anon_vma->root = anon_vma; // the two stores may be reordered vma->anon_vma = anon_vma; // finds A's anon_vma anon_vma = find_mergeable_anon_vma(vma); anon_vma_lock_write(anon_vma); // may still see the old root down_write(&anon_vma->root->rwsem); anon_vma_unlock_write(anon_vma); // see the new root, never unlock old up_write(&anon_vma->root->rwsem); thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma. __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store. anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time. While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem. The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered. The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them. The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect. As a result, thread B can observe the following order: vma->anon_vma = anon_vma; anon_vma->root = anon_vma; The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one. The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it. If that store isn't visible, thread B reads a root that points to the old anon_vma and locks it. As a result, thread B can call anon_vma_lock_write() with the old root, and call anon_vma_unlock_write() with the new root, leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore (its count is dropped from 0 to -1 due to wrong unlock). To fix it, change the plain store `vma->anon_vma = anon_vma` to store release, so that the fields of anon_vma are visible before anon_vma is published to vma->anon_vma. At read side, the load of anon_vma and anon_vma->root have address dependency. According to Documentation/memory-barriers.txt and some investigations, only Alpha needs address-dependency barriers and it has been handled by READ_ONCE() in reusable_anon_vma(). We reproduced this issue in v5.10 with KSM enabled. The kernel doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking VMA merging for new VMAs"), so there are many adjacent VMAs that aren't merged but are compatible for anon_vma. Without this fix, our production environment could reproduce this issue about 2-5 times each month. After adding a smp_mb() before anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different to this patch, this issue hasn't been reproduced for one month. Link: https://lore.kernel.org/20260908122924.554373-1-tujinjiang@huawei.com Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Lorenzo Stoakes (ARM) <ljs(a)kernel.org> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Harry Yoo <harry(a)kernel.org> Cc: Hiroyouki Kamezawa <kamezawa.hiroyu(a)jp.fujitsu.com> Cc: Jann Horn <jannh(a)google.com> Cc: Jinjiang Tu <tujinjiang(a)huawei.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Larry Woodman <lwoodman(a)redhat.com> Cc: Liam R. Howlett <liam(a)infradead.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: <stable(a)vger.kernel.org> Conflicts: mm/rmap.c mm/mmap.c mm/vma.c [Context conflicts.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/mmap.c | 7 +++++++ mm/rmap.c | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index c0262befcaae..604c0c877c5c 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1300,6 +1300,13 @@ static int anon_vma_compatible(struct vm_area_struct *a, struct vm_area_struct * * acceptable for merging, so we can do all of this optimistically. But * we do that READ_ONCE() to make sure that we never re-load the pointer. * + * The READ_ONCE() establishes an address dependency between anon_vma and + * any access to its fields, which pairs with the assignment to + * vma->anon_vma performed with release semantics in __anon_vma_prepare(). + * + * This is especially important as anon_vma's are SLAB_TYPESAFE_BY_RCU so + * accessing an uninitialised anon_vma's fields may result in a UAF. + * * IOW: that the "list_is_singular()" test on the anon_vma_chain only * matters for the 'stable anon_vma' case (ie the thing we want to avoid * is to return an anon_vma that is "complex" due to having gone through diff --git a/mm/rmap.c b/mm/rmap.c index 150803a7ffb5..fb07b2b32a91 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -206,7 +206,11 @@ int __anon_vma_prepare(struct vm_area_struct *vma) /* page_table_lock to protect against threads */ spin_lock(&mm->page_table_lock); if (likely(!vma->anon_vma)) { - vma->anon_vma = anon_vma; + /* + * Make anon_vma fields visible before anon_vma is published. + * Paired with an address dependency in reusable_anon_vma(). + */ + smp_store_release(&vma->anon_vma, anon_vma); anon_vma_chain_link(vma, avc, anon_vma); anon_vma->num_active_vmas++; allocated = NULL; -- 2.43.0

2 1