In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
Inthe Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueueenabling.Failure during workqueueenabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless asecond failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers aBUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueueenabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unlessa second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggersa BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
| linux | | https://git.kernel.org/linus/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f | https://git.kernel.org/linus/1f2bb40337f0df1d9af80793e9fdacff7706e654 | ubuntu |
</details>
二、漏洞分析结构反馈
影响性分析说明：
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.The Linux kernel CVE team has assigned CVE-2022-48868 to this issue.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.
