fkie_cve-2022-49159
Vulnerability from fkie_nvd
Published
2025-02-26 07:00
Modified
2025-02-26 07:00
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Implement ref count for SRB
The timeout handler and the done function are racing. When
qla2x00_async_iocb_timeout() starts to run it can be preempted by the
normal response path (via the firmware?). qla24xx_async_gpsc_sp_done()
releases the SRB unconditionally. When scheduling back to
qla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed
sp->qpair pointer:
qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21.
qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21
qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400.
qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5
BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx]
Obvious solution to this is to introduce a reference counter. One reference
is taken for the normal code path (the 'good' case) and one for the timeout
path. As we always race between the normal good case and the timeout/abort
handler we need to serialize it. Also we cannot assume any order between
the handlers. Since this is slow path we can use proper synchronization via
locks.
When we are able to cancel a timer (del_timer returns 1) we know there
can't be any error handling in progress because the timeout handler hasn't
expired yet, thus we can safely decrement the refcounter by one.
If we are not able to cancel the timer, we know an abort handler is
running. We have to make sure we call sp->done() in the abort handlers
before calling kref_put().
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Implement ref count for SRB\n\nThe timeout handler and the done function are racing. When\nqla2x00_async_iocb_timeout() starts to run it can be preempted by the\nnormal response path (via the firmware?). qla24xx_async_gpsc_sp_done()\nreleases the SRB unconditionally. When scheduling back to\nqla2x00_async_iocb_timeout() qla24xx_async_abort_cmd() will access an freed\nsp-\u003eqpair pointer:\n\n qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21.\n qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21\n qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400.\n qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5\n BUG: unable to handle kernel NULL pointer dereference at 0000000000000004\n IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx]\n\nObvious solution to this is to introduce a reference counter. One reference\nis taken for the normal code path (the \u0027good\u0027 case) and one for the timeout\npath. As we always race between the normal good case and the timeout/abort\nhandler we need to serialize it. Also we cannot assume any order between\nthe handlers. Since this is slow path we can use proper synchronization via\nlocks.\n\nWhen we are able to cancel a timer (del_timer returns 1) we know there\ncan\u0027t be any error handling in progress because the timeout handler hasn\u0027t\nexpired yet, thus we can safely decrement the refcounter by one.\n\nIf we are not able to cancel the timer, we know an abort handler is\nrunning. We have to make sure we call sp-\u003edone() in the abort handlers\nbefore calling kref_put()."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Implementar recuento de referencias para SRB El controlador de tiempo de espera y la funci\u00f3n done est\u00e1n en ejecuci\u00f3n. Cuando qla2x00_async_iocb_timeout() comienza a ejecutarse, puede ser interrumpido por la ruta de respuesta normal (\u00bfa trav\u00e9s del firmware?). qla24xx_async_gpsc_sp_done() libera el SRB incondicionalmente. Al programar de nuevo a qla2x00_async_iocb_timeout(), qla24xx_async_abort_cmd() acceder\u00e1 a un puntero sp-\u0026gt;qpair liberado: qla2xxx [0000:83:00.0]-2871:0: Tiempo de espera de Async-gpsc - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc SALIDA WWPN 20:45:00:27:f8:75:33:00 velocidades=2c00 velocidad=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xx_handle_gpsc_event 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 ERROR: no se puede manejar la desreferencia del puntero NULL del n\u00facleo en 0000000000000004 IP: qla24xx_async_abort_cmd+0x1b/0x1c0 [qla2xxx] La soluci\u00f3n obvia para esto es introducir un contador de referencia. Se toma una referencia para la ruta de c\u00f3digo normal (el caso \"bueno\") y otra para la ruta de tiempo de espera. Como siempre corremos entre el caso bueno normal y el controlador de tiempo de espera/aborto, necesitamos serializarlo. Adem\u00e1s, no podemos asumir ning\u00fan orden entre los controladores. Dado que esta es una ruta lenta, podemos usar la sincronizaci\u00f3n adecuada a trav\u00e9s de bloqueos. Cuando podemos cancelar un temporizador (del_timer devuelve 1), sabemos que no puede haber ning\u00fan manejo de errores en curso porque el manejador de tiempo de espera a\u00fan no ha expirado, por lo que podemos disminuir de manera segura el contador de referencias en uno. Si no podemos cancelar el temporizador, sabemos que se est\u00e1 ejecutando un manejador de aborto. Tenemos que asegurarnos de llamar a sp-\u0026gt;done() en los manejadores de aborto antes de llamar a kref_put()."
}
],
"id": "CVE-2022-49159",
"lastModified": "2025-02-26T07:00:53.103",
"metrics": {},
"published": "2025-02-26T07:00:53.103",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/31e6cdbe0eae37badceb5e0d4f06cf051432fd77"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ceda7f794f3dfe272491e93e3e93049f8be5f07b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e140723f78ff418c8df7d990e102e07b65c87d4a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e17111dd2fda81c35f309b1e5b6ab35809a375e7"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…