https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 22:23:16 +0000 https://cve.radiocsirt.org/vuln/cve-2024-26933 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>USB: core: Fix deadlock in port &#34;disable&#34; sysfs attribute</p> <p>The show and store callback routines for the &#34;disable&#34; sysfs attribute file in port.c acquire the device lock for the port&#39;s parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:</p> <p>Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and device_del() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can&#39;t be released until then.</p> <p>But the disable_show() or disable_store() routine can&#39;t return until after it has acquired the lock.</p> <p>The resulting deadlock can be avoided by calling sysfs_break_active_protection(). This will cause the sysfs core not to wait for the attribute&#39;s callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won&#39;t be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hub_get().</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>USB: core: Fix deadlock in port &#34;disable&#34; sysfs attribute</p> <p>The show and store callback routines for the &#34;disable&#34; sysfs attribute file in port.c acquire the device lock for the port&#39;s parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:</p> <p>Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and device_del() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can&#39;t be released until then.</p> <p>But the disable_show() or disable_store() routine can&#39;t return until after it has acquired the lock.</p> <p>The resulting deadlock can be avoided by calling sysfs_break_active_protection(). This will cause the sysfs core not to wait for the attribute&#39;s callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won&#39;t be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hub_get().</p> https://cve.radiocsirt.org/vuln/cve-2024-26933