Description
In the Linux kernel, the following vulnerability has been resolved:xenbus: Use kref to track req lifetimeMarek reported seeing a NULL pointer fault in the xenbus_threadcallstack:BUG: kernel NULL pointer dereference, address: 0000000000000000RIP: e030:__wake_up_common+0x4c/0x180Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), athin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seemslike it was xs_wake_up() in this case.It seems like req may have woken up the xs_wait_for_reply(), whichkfree()ed the req. When xenbus_thread resumes, it faults on the zero-eddata.Linux Device Drivers 2nd edition states:"Normally, a wake_up call can cause an immediate reschedule to happen,meaning that other processes might run before wake_up returns."... which would match the behaviour observed.Change to keeping two krefs on each request. One for the caller, andone for xenbus_thread. Each will kref_put() when finished, and the lastwill free it.This use of kref matches the description inDocumentation/core-api/kref.rst
POC
Reference
No PoCs from references.
Github
- https://github.com/ARPSyndicate/cve-scores
- https://github.com/fkie-cad/nvd-json-data-feeds
- https://github.com/runwhen-contrib/helm-charts
- https://github.com/w4zu/Debian_security
