CVE-2022-50459

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()<br /> <br /> Fix a NULL pointer crash that occurs when we are freeing the socket at the<br /> same time we access it via sysfs.<br /> <br /> The problem is that:<br /> <br /> 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take<br /> the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()<br /> does a get on the "struct sock".<br /> <br /> 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put<br /> on the "struct socket" and that does __sock_release() which sets the<br /> sock-&gt;ops to NULL.<br /> <br /> 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then<br /> call kernel_getpeername() which accesses the NULL sock-&gt;ops.<br /> <br /> Above we do a get on the "struct sock", but we needed a get on the "struct<br /> socket". Originally, we just held the frwd_lock the entire time but in<br /> commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while<br /> calling getpeername()") we switched to refcount based because the network<br /> layer changed and started taking a mutex in that path, so we could no<br /> longer hold the frwd_lock.<br /> <br /> Instead of trying to maintain multiple refcounts, this just has us use a<br /> mutex for accessing the socket in the interface code paths.