Bug 2217820 (CVE-2023-3355)
Summary: | CVE-2023-3355 kernel: NULL pointer dereference in submit_lookup_cmds() in drivers/gpu/drm/msm/msm_gem_submit.c | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Alex <allarkin> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | acaringi, allarkin, bhu, chwhite, crwood, dbohanno, ddepaula, debarbos, dvlasenk, ezulian, hkrzesin, jarod, jdenham, jfaracco, jferlan, jforbes, jlelli, joe.lawrence, jpazdziora, jshortt, jstancek, jwyatt, kcarcia, kernel-mgr, ldoskova, lgoncalv, lleshchi, lzampier, nmurray, ptalbert, qzhao, rrobaina, rvrbovsk, rysulliv, scweaver, tyberry, walters, wcosta, williams, wmealing, ycote, ymankad |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | kernel 6.1-rc8 | Doc Type: | If docs needed, set a value |
Doc Text: |
A NULL pointer dereference flaw was found in the Linux kernel's drivers/gpu/drm/msm/msm_gem_submit.c code in the submit_lookup_cmds function, which fails because it lacks a check of the return value of kmalloc(). This issue allows a local user to crash the system.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2023-06-27 12:07:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 2217821 | ||
Bug Blocks: | 2175060, 2182007 |
Description
Alex
2023-06-27 07:51:56 UTC
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2217821] Memory allocations with the GFP_KERNEL should not be considered as CVE if alloc small amount of memory (based on " GFP_KERNEL - both background and direct reclaim are allowed and the default page allocator behavior is used. That means that not costly allocation requests are basically no-fail but there is no guarantee of that behavior so failures have to be checked properly by callers (e.g. OOM killer victim is allowed to fail currently). ", and for more info see: https://lwn.net/Articles/627419/ ). However, particular for this CVE I'm not sure if always small amount of memory request, so it is just in case as potential security issue. This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2023-3355 This was fixed for Fedora with the 6.1.16 stable kernel updates. Hello Alex, while doing review of the Vulnerability Assessment report of RHEL 8.6 for the purpose of Common Criteria certification, we came across this CVE. Could you update the CVE page https://access.redhat.com/security/cve/CVE-2023-3355 with some publicly facing statement why we consider all RHELs as not affected? Especially given the https://www.kernel.org/doc/html/next/core-api/memory-allocation.html that you quoted in comment 3 says that "... but there is no guarantee of that behavior so failures have to be checked properly by callers". Thank you, Jan In reply to comment #7: > Hello Alex, > > while doing review of the Vulnerability Assessment report of RHEL 8.6 for > the purpose of Common Criteria certification, we came across this CVE. > > Could you update the CVE page > https://access.redhat.com/security/cve/CVE-2023-3355 with some publicly > facing statement why we consider all RHELs as not affected? Especially given > the > > https://www.kernel.org/doc/html/next/core-api/memory-allocation.html > > that you quoted in comment 3 says that "... but there is no guarantee of > that behavior so failures have to be checked properly by callers". > > Thank you, Jan Sure, added statement: "Related Kernel config param CONFIG_DRM_MSM enabled only for Fedora, so all versions of Red Hat Enterprise Linux not affected.". Perfect, thank you. |