In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Avoid undefined behavior: applying zero offset to null pointer
ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e
Before this change we see the following UBSAN stack trace in Fuchsia:
#0 0x000021e4213b3302 in acpidsinitamlwalk(struct acpiwalkstate*, union acpiparseobject*, struct acpinamespacenode*, u8*, u32, struct acpievaluateinfo*, u8) ../../thirdparty/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x000020d0f660777f in ubsangetstacktrace() compiler-rt/lib/ubsan/ubsandiag.cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 0x000020d0f660777f in maybeprintstacktrace() compiler-rt/lib/ubsan/ubsandiag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 0x000020d0f660777f in ~scopedreport() compiler-rt/lib/ubsan/ubsandiag.cpp:387 <libclang_rt.asan.so>+0x3d77f #2 0x000020d0f660b96d in handlepointeroverflowimpl() compiler-rt/lib/ubsan/ubsanhandlers.cpp:809 <libclang_rt.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsanhandlers.cpp:815 <libclang_rt.asan.so>+0x4150d #4 0x000021e4213b3302 in acpidsinitamlwalk(struct acpiwalkstate*, union acpiparseobject*, struct acpinamespacenode*, u8*, u32, struct acpievaluateinfo*, u8) ../../thirdparty/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 in acpidscallcontrolmethod(struct acpithreadstate*, struct acpiwalkstate*, union acpiparseobject*) ../../thirdparty/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpipsparseaml(struct acpiwalkstate*) ../../thirdparty/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 0x000021e4214464d2 in acpipsexecutemethod(struct acpievaluateinfo*) ../../thirdparty/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 0x000021e4213aa052 in acpinsevaluate(struct acpievaluateinfo*) ../../thirdparty/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413dd8 in acpinsinitonedevice(acpihandle, u32, void*, void**) ../../thirdparty/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 #10 0x000021e421429e98 in acpinswalknamespace(acpiobjecttype, acpihandle, u32, u32, acpiwalkcallback, acpiwalkcallback, void*, void**) ../../thirdparty/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 #11 0x000021e4214131ac in acpinsinitializedevices(u32) ../../thirdparty/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac #12 0x000021e42147c40d in acpiinitializeobjects(u32) ../../thirdparty/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d #13 0x000021e42126d603 in acpi::acpiimpl::initializeacpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603
Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/53xxx/CVE-2023-53182.json"
}