(2026.03 and earlier) Linux kernel local privilege escalation vulnerability (CVE-2026-31431) affecting infrastructure and VDI hosts

[junbo75]

Bug description

A high severity Linux kernel vulnerability (CVE-2026-31431, "Dirty Frag") has been identified that allows an authenticated local user to escalate privileges. Amazon Linux 2023 kernels used by RES infrastructure hosts and VDI hosts are affected. AWS has released updated AMIs with the patched kernel. Customers should update their RES environments to use the patched AMIs.

For more details, see AWS Security Bulletin 2026-026 and CVE-2026-31431.

Affected versions

2026.03 and earlier

Mitigation

RES environment with public internet access

Infrastructure hosts

WARNING: This is a disruptive operation. This script terminates all running infrastructure host instances. Your RES environment will be unavailable for at least 20 minutes while Auto Scaling Groups launch replacement instances with the patched AMI. DO NOT RUN this during active user sessions or production workloads. We would suggest to test in a non-production environment first.

The following script updates the AMI used by RES infrastructure hosts (cluster-manager, vdc-controller, vdc-broker, vdc-gateway, bastion-host) to a patched Amazon Linux 2023 AMI, then cycles the instances to apply the change.

1. Download the patch script (Attach here for local testing before publishing it to the S3 bucket patch_cve_2026_31431.sh):
   1. The script requires AWS CLI v2 and Python 3.
   2. Configure the AWS CLI for the account and region where RES is deployed. The executing role needs permissions for EC2 (launch templates, instances), Auto Scaling, and DynamoDB.
   3. Replace <output-directory> and <res-version> with the directory to download the patch script and RES version.

OUTPUT_DIRECTORY=<output-directory>
RES_VERSION=<res-version>  # e.g. 2025.06, 2025.06.01, 2025.09

mkdir -p ${OUTPUT_DIRECTORY}
curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patch_cve_2026_31431.sh --output ${OUTPUT_DIRECTORY}/patch_cve_2026_31431.sh
chmod +x ${OUTPUT_DIRECTORY}/patch_cve_2026_31431.sh

2. Run in dry-run mode to verify what will be changed:
   1. Replace <environment-name> and <aws-region> with your RES environment name and deployment region.

ENVIRONMENT_NAME=<environment-name>
REGION=<aws-region>

${OUTPUT_DIRECTORY}/patch_cve_2026_31431.sh -e ${ENVIRONMENT_NAME} -r ${REGION} -v ${RES_VERSION} --dry-run

3. Apply the patch:

${OUTPUT_DIRECTORY}/patch_cve_2026_31431.sh -e ${ENVIRONMENT_NAME} -r ${REGION} -v ${RES_VERSION}

If using a named AWS CLI profile:

• Replace <profile-name> with the profile name.

PROFILE_NAME=<profile-name>

${OUTPUT_DIRECTORY}/patch_cve_2026_31431.sh -e ${ENVIRONMENT_NAME} -r ${REGION} -v ${RES_VERSION} -p ${PROFILE_NAME}

4. Verify that new instances launch successfully by checking the following Auto Scaling Groups in the EC2 console:

• <environment-name>-cluster-manager-asg
• <environment-name>-vdc-controller-asg
• <environment-name>-vdc-broker-asg (Or <environment-name>-vdc_broker-asg depending on the RES version)
• <environment-name>-vdc-dcv-connection-gateway-asg (Or <environment-name>-vdc-dcv_connection_gateway-asg depending on the RES version)

5. For the bastion host: go to the RES Web UI → Environment Management → disable the bastion host, then re-enable it.

VDI hosts

This script above does NOT patch existing or future VDI instances. VDI hosts use AMIs defined in your software stacks, which are managed separately.

To address the vulnerability on VDI hosts:

1. (For 2025.06 and 2025.09 only) Apply the gcc dependency patch:
   1. The patch script requires AWS CLI v2, Python 3.9, and Boto3.
   2. Configure the AWS CLI for the account/region where RES is deployed with S3 write permissions to the RES bucket.
   3. Replace <output-directory>, <environment-name>, <res-version> with the directory to download the patch script, RES environment name and RES version.

OUTPUT_DIRECTORY=<output-directory>
ENVIRONMENT_NAME=<environment-name>
RES_VERSION=<res-version>  # 2025.06, 2025.06.01, or 2025.09

mkdir -p ${OUTPUT_DIRECTORY}
curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patch.py --output ${OUTPUT_DIRECTORY}/patch.py
curl https://research-engineering-studio-us-east-1.s3.amazonaws.com/releases/${RES_VERSION}/patch_scripts/patches/gcc_dependency_fix.patch --output ${OUTPUT_DIRECTORY}/gcc_dependency_fix.patch

python3 ${OUTPUT_DIRECTORY}/patch.py --environment-name ${ENVIRONMENT_NAME} --res-version ${RES_VERSION} --module installation --patch ${OUTPUT_DIRECTORY}/gcc_dependency_fix.patch

2. Update your software stack AMIs — Update your software stacks in the RES Web UI using new AMIs with the patched kernel for your OS (Amazon Linux 2023, RHEL, Rocky Linux, or Ubuntu).
3. Relaunch affected VDIs — Existing VDI sessions continue running on the vulnerable kernel until they are stopped/terminated and relaunched with the updated software stack.

Refer to your OS vendor's security advisory to confirm your AMI includes the fix:

• Amazon Linux : https://explore.alas.aws.amazon.com/CVE-2026-31431.html
• RHEL and Rocky Linux: https://access.redhat.com/security/cve/cve-2026-31431
• Ubuntu: https://ubuntu.com/security/CVE-2026-31431

RES environment without public internet access

1. (For 2025.06 to 2025.09 only) Apply the same gcc dependency patch as VDI hosts.
2. Create new RES-ready AMIs following the RES public doc corresponding to your RES version.
   1. (For 2025.06 to 2025.09 only), update the image builder component to download the patched installation script package from the <environment-name>-cluster-<aws-region>-<aws-account-id> S3 bucket under your own AWS account.
3. Use the provided patching script from RES environment with public internet access as an example (i.e. replace the target AMI ID), replace the infra and VDI hosts AMIs in your existing RES environment accordingly.

Rollback

For 2025.06 and 2025.09 (gcc patch): Re-run patch.py with the same patch file — the script toggles the patch (applying it again will unpatch).

For all versions (AMI update):

To revert an infrastructure host component to its previous AMI:

1. Get the launch template ID for the component:
   1. Replace <environment-name> and <component> with your RES environment name and component to rollback (one of: cluster-manager, vdc-controller, vdc-broker, vdc-gateway).

ENVIRONMENT_NAME=<environment-name>
COMPONENT=<component>

aws autoscaling describe-auto-scaling-groups \
--auto-scaling-group-names ${ENVIRONMENT_NAME}-${COMPONENT}-asg \
--query 'AutoScalingGroups[0].LaunchTemplate' --output table

2. List launch template versions to find the previous AMI:
   1. Replace <lt-id> with the launch template ID to rollback.

LAUNCH_TEMPLATE_ID=<lt-id>

aws ec2 describe-launch-template-versions \
--launch-template-id ${LAUNCH_TEMPLATE_ID} \
--query 'LaunchTemplateVersions[].{Version:VersionNumber,AMI:LaunchTemplateData.ImageId}' --output table

3. Revert the autoscaling group to the previous version and terminate instances:
   1. Replace <version> with the rollback version.

VERSION=<version>

aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name ${ENVIRONMENT_NAME}-${COMPONENT}-asg \
--launch-template "LaunchTemplateId=${LAUNCH_TEMPLATE_ID},Version=${VERSION}"

Then terminate the running instance from the EC2 console or CLI. The auto scaling group will relaunch with the reverted AMI.

For the bastion host, update the bastion-host.instance_ami key in the <environment-name>.cluster-settings DynamoDB table to the previous AMI ID, then disable and re-enable the bastion host from the RES Web UI.

---