CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41097 – usb: atm: cxacru: fix endpoint checking in cxacru_bind()
https://notcve.org/view.php?id=CVE-2024-41097
In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix endpoint checking in cxacru_bind() Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 • https://git.kernel.org/stable/c/902ffc3c707c1d459ea57428a619a807cbe412f9 https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47 https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506 https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727 https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4 https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b91090 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41095 – drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
https://notcve.org/view.php?id=CVE-2024-41095
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. A flaw was found in the Linux kernel’s nouveau module. The return value of the drm_mode_duplicate function is not checked in the nv17_tv_get_ld_modes function in the drivers/gpu/drm/nouveau/dispnv04/tvnv17.c file, possibly causing a NULL pointer dereference and resulting in a denial of service. • https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389 https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49 https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8 https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72 https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714 https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b09 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-41093 – drm/amdgpu: avoid using null object of framebuffer
https://notcve.org/view.php?id=CVE-2024-41093
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. • https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447 https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800 https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46 https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb https://access.redhat.com/security/cve/CVE-2024-41093 https://bugzilla.redhat.com/show_bug.cgi?id=2300488 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41089 – drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
https://notcve.org/view.php?id=CVE-2024-41089
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. • https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51 https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50 https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0 https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637 https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59 https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-41082 – nvme-fabrics: use reserved tag for reg read/write command
https://notcve.org/view.php?id=CVE-2024-41082
In the Linux kernel, the following vulnerability has been resolved: nvme-fabrics: use reserved tag for reg read/write command In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf: 1. For the disable ctrl path, we will not issue connect command 2. • https://git.kernel.org/stable/c/165da9c67a26f08c9b956c15d701da7690f45bcb https://git.kernel.org/stable/c/7dc3bfcb4c9cc58970fff6aaa48172cb224d85aa https://access.redhat.com/security/cve/CVE-2024-41082 https://bugzilla.redhat.com/show_bug.cgi?id=2300459 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •