Page 4 of 2219 results (0.005 seconds)

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts. • https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58 https://git.kernel.org/stable/c/ede596b1434b57c0b3fd5c02b326efe5c54f6e48 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() We handle errors here properly, ENOMEM isn't fatal, return the error. • https://git.kernel.org/stable/c/704c359b4093a2af650a20eaa030c435d7c30f91 https://git.kernel.org/stable/c/a580fb2c3479d993556e1c31b237c9e5be4944a3 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information. • https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d https://git.kernel.org/stable/c/71291aa7246645ef622621934d2067400380645e https://git.kernel.org/stable/c/c60676b81fab456b672796830f6d8057058f029c https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32 https://git.kernel.org/stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b https://git.kernel.org/stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9 https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16 https://git.kernel.org/stable/c/b8ccef048354074a548f108e51d0557d6 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: validate endpoint index for ast udc We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array. Found by static analysis. • https://git.kernel.org/stable/c/31bd4fab49c0adc6228848357c1b1df9395858af https://git.kernel.org/stable/c/b2a50ffdd1a079869a62198a8d1441355c513c7c https://git.kernel.org/stable/c/6fe9ca2ca389114c8da66e534c18273497843e8a https://git.kernel.org/stable/c/ee0d382feb44ec0f445e2ad63786cd7f3f6a8199 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix smatch static checker warning adev->gfx.imu.funcs could be NULL • https://git.kernel.org/stable/c/d40c2c3dd0395fe7fdc19bd96551e87251426d66 https://git.kernel.org/stable/c/8bc7b3ce33e64c74211ed17aec823fc4e523426a https://git.kernel.org/stable/c/c2056c7a840f0dbf293bc3b0d91826d001668fb0 https://git.kernel.org/stable/c/bdbdc7cecd00305dc844a361f9883d3a21022027 •