diff --git a/modules/rn-ocp-release-notes-known-issues.adoc b/modules/rn-ocp-release-notes-known-issues.adoc
index 0b15ef9544..d1277db3c4 100644
--- a/modules/rn-ocp-release-notes-known-issues.adoc
+++ b/modules/rn-ocp-release-notes-known-issues.adoc
@@ -4,7 +4,7 @@
 
 This section includes several known issues for {product-title} {product-version}.
 
-* If you mirrored the {product-title} release images to the registry of a disconnected environment by using the `oc adm release mirror` command, the release image Sigstore signature is not mirrored with the image. 
+* If you mirrored the {product-title} release images to the registry of a disconnected environment by using the `oc adm release mirror` command, the release image Sigstore signature is not mirrored with the image.
 +
 This has become an issue in {product-title} {product-version}, because the `openshift` cluster image policy is now deployed to the cluster by default. This policy causes CRI-O to automatically verify the Sigstore signature when pulling images into a cluster.  (link:https://issues.redhat.com/browse/OCPBUGS-70297[OCPBUGS-70297])
 +
@@ -17,7 +17,7 @@ If you cannot use the oc-mirror plugin v2, you can use the `oc image mirror` com
 ----
 $ oc image mirror "quay.io/openshift-release-dev/ocp-release:${RELEASE_DIGEST}.sig" "${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${RELEASE_DIGEST}.sig"
 ----
-where: 
+where:
 
 `RELEASE_DIGEST`:: Specifies your digest image with the `:` character replaced by a `-` character. For example: `sha256:884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee` becomes `sha256-884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee.sig`.
 --
@@ -25,3 +25,9 @@ where:
 For information on the oc-mirror v2 plugin, see _Mirroring images for a disconnected installation by using the oc-mirror plugin v2_.
 
 * Starting with {product-title} 4.21, there is a decrease in the default maximum open files soft limit for containers. As a consequence, end users might experience application failures. To work around this problem, increase the container runtimes (CRI-O) ulimit configuration using a method of your choice, such as the `ulimit` command. (link:https://issues.redhat.com/browse/OCPBUGS-62095[OCPBUGS-62095])
+
+* Currently, on clusters with SR-IOV network virtual functions configured, a race condition might occur between system services responsible for network device renaming and the TuneD service managed by the Node Tuning Operator. As a consequence, the TuneD profile might become degraded after the node restarts, leading to performance degradation. As a workaround, restart the TuneD pod to restore the profile state. (link:https://issues.redhat.com/browse/OCPBUGS-41934[OCPBUGS-41934])
+
+* Currently, pods that use a `guaranteed` QoS class and request whole CPUs might not restart automatically after a node reboot or kubelet restart. The issue might occur in nodes configured with a static CPU Manager policy and using the `full-pcpus-only` specification, and when most or all CPUs on the node are already allocated by such workloads. As a workaround, manually delete and re-create the affected pods. (link:https://issues.redhat.com/browse/OCPBUGS-43280[OCPBUGS-43280])
+
+* On systems using specific AMD EPYC processors, some low-level system interrupts, for example `AMD-Vi`, might contain CPUs in the CPU mask that overlaps with CPU-pinned workloads. This behavior is because of the hardware design. These specific error-reporting interrupts are generally inactive and there is currently no known performance impact.(link:https://issues.redhat.com/browse/OCPBUGS-57787[OCPBUGS-57787])
\ No newline at end of file