CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48866 – HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts
https://notcve.org/view.php?id=CVE-2022-48866
In the Linux kernel, the following vulnerability has been resolved: HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug. The root case is in missing validation check of actual number of endpoints. Code should not blindly access usb_host_interface::endpoint array, since it may contain less endpoints than code expects. Fix it by adding missing validaion check and print an error if number of endpoints do not match expected number En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: hid-thrustmaster: corrige la lectura OOB en Thrustmaster_interrupts Syzbot informó un error de lectura fuera de los límites en Thrustmaster_probe(). El caso raíz es la falta de verificación de validación del número real de endpoints. El código no debe acceder ciegamente a usb_host_interface::endpoint array, ya que puede contener menos endpoints de los que espera el código. Solucionelo agregando una verificación de validación faltante e imprima un error si el número de endpoints no coincide con el número esperado • https://git.kernel.org/stable/c/c49c33637802a2c6957a78119eb8be3b055dd9e9 https://git.kernel.org/stable/c/3ffbe85cda7f523dad896bae08cecd8db8b555ab https://git.kernel.org/stable/c/56185434e1e50acecee56d8f5850135009b87947 https://git.kernel.org/stable/c/fc3ef2e3297b3c0e2006b5d7b3d66965e3392036 https://access.redhat.com/security/cve/CVE-2022-48866 https://bugzilla.redhat.com/show_bug.cgi?id=2298640 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48865 – tipc: fix kernel panic when enabling bearer
https://notcve.org/view.php?id=CVE-2022-48865
In the Linux kernel, the following vulnerability has been resolved: tipc: fix kernel panic when enabling bearer When enabling a bearer on a node, a kernel panic is observed: [ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc] ... [ 4.520030] Call Trace: [ 4.520689] <IRQ> [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc] [ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc] [ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc] [ 4.525292] tipc_rcv+0x5da/0x730 [tipc] [ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0 [ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc] [ 4.528737] __netif_receive_skb_list_core+0x20b/0x260 [ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0 [ 4.531450] ? dev_gro_receive+0x4c2/0x680 [ 4.532512] napi_complete_done+0x6f/0x180 [ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net] ... The node in question is receiving activate messages in another thread after changing bearer status to allow message sending/ receiving in current thread: thread 1 | thread 2 -------- | -------- | tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } | Monitoring pointer in thread 2 is dereferenced before monitoring data is allocated in thread 1. • https://git.kernel.org/stable/c/35c55c9877f8de0ab129fa1a309271d0ecc868b9 https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5 https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71 https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94 https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48864 – vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command
https://notcve.org/view.php?id=CVE-2022-48864
In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command request from the driver, presently there is no validation against the number of queue pairs to configure, or even if multiqueue had been negotiated or not is unverified. This may lead to kernel panic due to uninitialized resource for the queues were there any bogus request sent down by untrusted driver. Tie up the loose ends there. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vdpa/mlx5: agregar validación para el comando VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET Cuando control vq recibe una solicitud de comando VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET del controlador, actualmente no hay validación contra el número de pares de colas para configurar, o incluso si La multicola se había negociado o no no está verificada. Esto puede provocar pánico en el kernel debido a recursos no inicializados para las colas si hubo alguna solicitud falsa enviada por un controlador que no es de confianza. • https://git.kernel.org/stable/c/52893733f2c5886fc74be6c386d12b59a3f581df https://git.kernel.org/stable/c/e7e118416465f2ba8b55007e5b789823e101421e https://git.kernel.org/stable/c/9f6effca75626c7a7c7620dabcb1a254ca530230 https://git.kernel.org/stable/c/ed0f849fc3a63ed2ddf5e72cdb1de3bdbbb0f8eb • CWE-908: Use of Uninitialized Resource •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48863 – mISDN: Fix memory leak in dsp_pipeline_build()
https://notcve.org/view.php?id=CVE-2022-48863
In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix memory leak in dsp_pipeline_build() dsp_pipeline_build() allocates dup pointer by kstrdup(cfg), but then it updates dup variable by strsep(&dup, "|"). As a result when it calls kfree(dup), the dup variable contains NULL. Found by Linux Driver Verification project (linuxtesting.org) with SVACE. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mISDN: corrige la pérdida de memoria en dsp_pipeline_build() dsp_pipeline_build() asigna el puntero dup mediante kstrdup(cfg), pero luego actualiza la variable dup mediante strsep(&dup, "|"). Como resultado, cuando llama a kfree(dup), la variable dup contiene NULL. Encontrado por el proyecto de verificación de controladores de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/960366cf8dbb3359afaca30cf7fdbf69a6d6dda7 https://git.kernel.org/stable/c/a3d5fcc6cf2ecbba5a269631092570aa285a24cb https://git.kernel.org/stable/c/7777b1f795af1bb43867375d8a776080111aae1b https://git.kernel.org/stable/c/640445d6fc059d4514ffea79eb4196299e0e2d0f https://git.kernel.org/stable/c/c6a502c2299941c8326d029cfc8a3bc8a4607ad5 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48862 – vhost: fix hung thread due to erroneous iotlb entries
https://notcve.org/view.php?id=CVE-2022-48862
In the Linux kernel, the following vulnerability has been resolved: vhost: fix hung thread due to erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at: https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. • https://git.kernel.org/stable/c/0bbe30668d89ec8a309f28ced6d092c90fb23e8c https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1 https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •