Uploaded image for project: 'CoreOS OCP'
  1. CoreOS OCP
  2. COS-2437

Impact Statement: error loading seccomp filter: errno 524

XMLWordPrintable

    • Icon: Spike Spike
    • Resolution: Done
    • Icon: Major Major
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • 0
    • 0

      We're asking the following questions to evaluate whether or not OCPBUGS-16655 warrants changing update recommendations from either the previous X.Y or X.Y.Z. The ultimate goal is to avoid recommending an update which introduces new risk or reduces cluster functionality in any way. In the absence of a declared update risk (the status quo), there is some risk that the existing fleet updates into the at-risk releases. Depending on the bug and estimated risk, leaving the update risk undeclared may be acceptable.

      I have filled in answers based on my understanding of the issue, please check whether my answers are correctly capturing the real state of things.

      Which 4.y.z to 4.y'.z' updates increase vulnerability?

      4.12 to 4.13 up to 4.13.9. 4.13.10 should contain the fix.

      Which types of clusters?

      Any cluster with sufficient load (clusters executing more pods are more likely to hit this issue)


      The two questions above are sufficient to declare an initial update risk, and we would like as much detail as possible on them as quickly as you can get it. Perfectly crisp responses are nice, but are not required. For example "it seems like these platforms are involved, because..." in a day 1 draft impact statement is helpful, even if you follow up with "actually, it was these other platforms" on day 3. In the absence of a response within 7 days, we may or may not declare a conditional update risk based on our current understanding of the issue.

      If you can, answers to the following questions will make the conditional risk declaration more actionable for customers.

      What is the impact? Is it serious enough to warrant removing update recommendations?

      New Pods fail to execute and get stuck in CreateContainerError

      How involved is remediation?

      There's a workaround that needs to be executed on any node that becomes affected: net.core.bpf_jit_limit can be increased from the original value to a new, higher one with sysctl net.core.bpf_jit_limit=<value>

      Is this a regression?

      Yes, this is a RHEL kernel regression between 8.6 and 9.2 kernels.

            mnguyen@redhat.com Michael Nguyen
            afri@afri.cz Petr Muller
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: