Preface: The first-level (L1) cache is small enough to provide a one- or two-cycle access time. The second-level (L2) cache is also built from SRAM but is larger, and therefore slower, than the L1 cache. The processor first looks for the data in the L1 cache. If the L1 cache misses, the processor looks in the L2 cache.

Background: Refer to diagram. If a multiple request on point 2 and 3. In normal circumstances, the ID number will be added each time the number is found. Therefore, the URL field might end up looking like example shown below:

2,2,2,4,7,8,8,8,8,8,9,9

So above result has a significant influence on the performance of an algorithm, but in Java You have close to no control over how your data is arranged in memory. If this issue happen in CPU. The processor first looks for the data in the L1 cache. If CPU manufacturer do not focus this matter in design phase. Perhaps it will hit this vulnerability.

Vulnerability details:

CVE-2023-38468 – In urild service, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service with System execution privileges needed

CVE-2023-38467 – In urild service, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service with System execution privileges needed

Official announcement: For details, please refer to the link – https://www.unisoc.com/en_us/secy/announcementDetail/1698296481653522434