All read-only mounts set through the CSI plugin have failed.

Description

We uniformly configure read-only mounts for program areas of a specific type of volume through the CSI component, so ordinary services don't need to be aware that they are automatically mounted in read-only mode. However, due to the following changes, the read-only restriction has failed, and the mounted directories within the containers have become writable, posing a security risk.
https://github.com/opencontainers/runc/releases/tag/v1.2.0-rc.1

Steps to reproduce the issue

Using an extended CSI component, the host directory /opt/data is mounted to the pod directory /var/lib/kubelet/pods/xxx/volumes/kubernetes.io~csi/pkg/mount. The mount parameters include the configuration of ro (read-only).
In a regular pod configuration, the extended CSI is used to mount the directory to the /opt/test directory inside the container. This step is performed by runc.
After entering the container, it is possible to create new files in the /opt/test directory.

Describe the results you received and expected

I expect that when entering the /opt/test directory in the container, it should be in read-only mode, preventing the creation or modification of files.

What version of runc are you using?

runc version 1.2.4
commit: v1.2.4-0-g6c52b3f
spec: 1.2.0
go: go1.24.1
libseccomp: 2.5.0

Host OS information

NAME="EulerOS"
VERSION="2.0 (SP13x86_64)"
ID="euleros"
VERSION_ID="2.0"
PRETTY_NAME="EulerOS 2.0 (SP13x86_64)"
ANSI_COLOR="0;31"

Host kernel information

Linux master1 5.10.0

Start by reproducing the CSI mount scenario described in the issue with runc v1.2.4 and inspect the container mount-handling entry points involved. Confirm the /opt/test mount loses its read-only restriction, then add coverage for the reported setup and verify that file creation and modification are rejected.