Bug 1202010 - (CVE-2022-36123) VUL-0: CVE-2022-36123: kernel-source,kernel-source-azure,kernel-source-rt: lacks of certain clear operation for the block starting symbol (.bss) could cause DoS
VUL-0: CVE-2022-36123: kernel-source,kernel-source-azure,kernel-source-rt: la...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Jürgen Groß
Security Team bot
Depends on:
Blocks: 1202583
  Show dependency treegraph
Reported: 2022-08-01 08:09 UTC by Robert Frohl
Modified: 2022-08-23 08:12 UTC (History)
2 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Petr Mladek 2022-08-01 12:13:07 UTC
Juergen, it seems that you have fixed this upstream.

Please, backport this into SUSE kernels where appropriate.
Or assign it to a coleague who could do so.
Comment 2 Jürgen Groß 2022-08-01 13:02:53 UTC
Hmm, is this really needed in any of our kernels?

The real issue has been introduced in 5.19-rc3 via commit e32683c6f7d2, and the fix was in 5.19-rc7.

Note that before above commit the .brk area (which is the main problem in this case) was properly cleared by Xen. Commit e32683c6f7d2 was wrong by resulting in the program headers of the kernel not covering .brk in the to be allocated memory, which in turn led to early page tables not being zeroed properly.

The reasoning in the CVE report is wrong in many aspects. .bss is cleared by the kernel just fine. The claim that user code in Xen PV guests can cause DoS or gain privileges is just a claim without any proof. It would need a boot loader to not honor alloc-only sections of the loaded kernel to be cleared, which is AFAIK a recommendation for the loader.
Comment 5 Robert Frohl 2022-08-23 08:12:17 UTC
The problem was incorrectly identified to affect a wider range of kernels (i.e. 5.18.13). Only 5.19rc is affected by this.

8b87d8cec1b31 is not related to the issue, e32683c6f7d2 introduced the problem instead.

not relevant for us, closing