Page 286 of 2771 results (0.012 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Update error handler for UCTX and UMEM In the fast unload flow, the device state is set to internal error, which indicates that the driver started the destroy process. In this case, when a destroy command is being executed, it should return MLX5_CMD_STAT_OK. Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK instead of EIO. This fixes a call trace in the umem release process - [ 2633.536695] Call Trace: [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core] [ 2633.539641] disable_device+0x8c/0x130 [ib_core] [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core] [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core] [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib] [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary] [ 2633.544661] device_release_driver_internal+0x103/0x1f0 [ 2633.545679] bus_remove_device+0xf7/0x170 [ 2633.546640] device_del+0x181/0x410 [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core] [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core] [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core] [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core] [ 2633.551819] pci_device_remove+0x3b/0xc0 [ 2633.552731] device_release_driver_internal+0x103/0x1f0 [ 2633.553746] unbind_store+0xf6/0x130 [ 2633.554657] kernfs_fop_write+0x116/0x190 [ 2633.555567] vfs_write+0xa5/0x1a0 [ 2633.556407] ksys_write+0x4f/0xb0 [ 2633.557233] do_syscall_64+0x5b/0x1a0 [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 2633.559018] RIP: 0033:0x7f9977132648 [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648 [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001 [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740 [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0 [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c [ 2633.568725] ---[ end trace 10b4fe52945e544d ]--- • https://git.kernel.org/stable/c/6a6fabbfa3e8c656ff906ae999fb6856410fa4cd https://git.kernel.org/stable/c/a51a6da375d82aed5c8f83abd13e7d060421bd48 https://git.kernel.org/stable/c/ba50cd9451f6c49cf0841c0a4a146ff6a2822699 •

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix null pointer dereference on pointer cs_desc The pointer cs_desc return from snd_usb_find_clock_source could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference. • https://git.kernel.org/stable/c/58fa50de595f152900594c28ec9915c169643739 https://git.kernel.org/stable/c/b97053df0f04747c3c1e021ecbe99db675342954 •

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

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Remove WARN_ON in tps6598x_block_read Calling tps6598x_block_read with a higher than allowed len can be handled by just returning an error. There's no need to crash systems with panic-on-warn enabled. • https://git.kernel.org/stable/c/2a897d384513ba7f7ef05611338b9a6ec6aeac00 https://git.kernel.org/stable/c/30dcfcda8992dc42f18e7d35b6a1fa72372d382d https://git.kernel.org/stable/c/eff8b7628410cb2eb562ca0d5d1f12e27063733e https://git.kernel.org/stable/c/2c71811c963b6c310a29455d521d31a7ea6c5b5e https://git.kernel.org/stable/c/b7a0a63f3fed57d413bb857de164ea9c3984bc4e •

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: gus: fix null pointer dereference on pointer block The pointer block return from snd_gf1_dma_next_block could be null, so there is a potential null pointer dereference issue. Fix this by adding a null check before dereference. • https://git.kernel.org/stable/c/3e28e083dcdf03a18a083f8a47b6bb6b1604b5be https://git.kernel.org/stable/c/cb09c760c201f82df83babc92a5ffea0a01807fc https://git.kernel.org/stable/c/542fa721594a02d2aee0370a764d306ef48d030c https://git.kernel.org/stable/c/ab4c1ebc40f699f48346f634d7b72b9c5193f315 https://git.kernel.org/stable/c/c6d2cefdd05c4810c416fb8d384b5c377bd977bc https://git.kernel.org/stable/c/1ac6cd87d8ddd36c43620f82c4d65b058f725f0f https://git.kernel.org/stable/c/16721797dcef2c7c030ffe73a07f39a65f9323c3 https://git.kernel.org/stable/c/a0d21bb3279476c777434c40d969ea88c •

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

In the Linux kernel, the following vulnerability has been resolved: usb: host: ohci-tmio: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. • https://git.kernel.org/stable/c/28e016e02118917e50a667bc72fb80098cf2b460 https://git.kernel.org/stable/c/2f18f97a1a787154a372c0738f1576f14b693d91 https://git.kernel.org/stable/c/bb6ed2e05eb6e8619b30fa854f9becd50c11723f https://git.kernel.org/stable/c/951b8239fd24678b56c995c5c0456ab12e059d19 https://git.kernel.org/stable/c/f98986b7acb4219f95789095eced93ed69d81d35 https://git.kernel.org/stable/c/2474eb7fc3bfbce10f7b8ea431fcffe5dd5f5100 https://git.kernel.org/stable/c/065334f6640d074a1caec2f8b0091467a22f9483 https://git.kernel.org/stable/c/9eff2b2e59fda25051ab36cd1cb501466 •