CVE-2023-53777 Affecting kernel-source-azure package, versions <6.4.0-150700.20.24.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.03% (10th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-SLES157-KERNELSOURCEAZURE-15104731
  • published27 Jan 2026
  • disclosed23 Jan 2026

Introduced: 23 Jan 2026

CVE-2023-53777  (opens in a new tab)

How to fix?

Upgrade SLES:15.7 kernel-source-azure to version 6.4.0-150700.20.24.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-source-azure package and not the kernel-source-azure package as distributed by SLES. See How to fix? for SLES:15.7 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

erofs: kill hooked chains to avoid loops on deduplicated compressed images

After heavily stressing EROFS with several images which include a hand-crafted image of repeated patterns for more than 46 days, I found two chains could be linked with each other almost simultaneously and form a loop so that the entire loop won't be submitted. As a consequence, the corresponding file pages will remain locked forever.

It can be only observed on data-deduplicated compressed images. For example, consider two chains with five pclusters in total: Chain 1: 2->3->4->5 -- The tail pcluster is 5; Chain 2: 5->1->2 -- The tail pcluster is 2.

Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link to Chain 2 at the same time with pcluster 2.

Since hooked chains are all linked locklessly now, I have no idea how to simply avoid the race. Instead, let's avoid hooked chains completely until I could work out a proper way to fix this and end users finally tell us that it's needed to add it back.

Actually, this optimization can be found with multi-threaded workloads (especially even more often on deduplicated compressed images), yet I'm not sure about the overall system impacts of not having this compared with implementation complexity.

CVSS Base Scores

version 3.1