Page 381 of 4592 results (0.011 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: Revert "media: v4l2-ctrls: show all owned controls in log_status" This reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739. This patch introduced a potential deadlock scenario: [Wed May 8 10:02:06 2024] Possible unsafe locking scenario: [Wed May 8 10:02:06 2024] CPU0 CPU1 [Wed May 8 10:02:06 2024] ---- ---- [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); For now just revert. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "media: v4l2-ctrls: mostrar todos los controles de propiedad en log_status" Esto revierte el commit 9801b5b28c6929139d6fceeee8d739cc67bb2739. Este parche introdujo un posible escenario de bloqueo: [miércoles 8 de mayo 10:02:06 2024] Posible escenario de bloqueo inseguro: [miércoles 8 de mayo 10:02:06 2024] CPU0 CPU1 [miércoles 8 de mayo 10:02:06 2024] -- -- ---- [miércoles 8 de mayo 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Miércoles 8 de mayo 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); [Miércoles 8 de mayo 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock); [Miércoles 8 de mayo 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock); Por ahora simplemente revertir. • https://git.kernel.org/stable/c/9801b5b28c6929139d6fceeee8d739cc67bb2739 https://git.kernel.org/stable/c/2e0ce54a9c5c7013b1257be044d99cbe7305e9f1 https://git.kernel.org/stable/c/eba63df7eb1f95df6bfb67722a35372b6994928d •

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

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Do not use WARN when encode fails When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LLAVES: confiable: no usar WARN cuando falla la codificación Cuando falla asn1_encode_sequence(), WARN no es la solución correcta. 1. asn1_encode_sequence() no es una función interna (ubicada en lib/asn1_encode.c). 2. Se conoce la ubicación, lo que hace que el seguimiento de la pila sea inútil. 3. • https://git.kernel.org/stable/c/f2219745250f388edacabe6cca73654131c67d0a https://git.kernel.org/stable/c/96f650995c70237b061b497c66755e32908f8972 https://git.kernel.org/stable/c/681935009fec3fc22af97ee312d4a24ccf3cf087 https://git.kernel.org/stable/c/1c652e1e10676f942149052d9329b8bf2703529a https://git.kernel.org/stable/c/d32c6e09f7c4bec3ebc4941323f0aa6366bc1487 https://git.kernel.org/stable/c/ff91cc12faf798f573dab2abc976c1d5b1862fea https://git.kernel.org/stable/c/050bf3c793a07f96bd1e2fd62e1447f731ed733b •

CVSS: 6.1EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided, taprio_parse_mqprio_opt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called. First call (with valid attributes) sets dev->num_tc to a non zero value. Second call (with arbitrary mqprio attributes) returns early from taprio_parse_mqprio_opt() and bad things can happen. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: validar siempre TCA_TAPRIO_ATTR_PRIOMAP Si se ha proporcionado un atributo TCA_TAPRIO_ATTR_PRIOMAP, taprio_parse_mqprio_opt() debe validarlo, o el espacio de usuario puede inyectar datos arbitrarios al kernel, la segunda vez taprio_change () se llama. La primera llamada (con atributos válidos) establece dev->num_tc en un valor distinto de cero. La segunda llamada (con atributos mqprio arbitrarios) regresa temprano desde taprio_parse_mqprio_opt() y pueden suceder cosas malas. • https://git.kernel.org/stable/c/a3d43c0d56f1b94e74963a2fbadfb70126d92213 https://git.kernel.org/stable/c/c6041e7124464ce7e896ee3f912897ce88a0c4ec https://git.kernel.org/stable/c/6db4af09987cc5d5f0136bd46148b0e0460dae5b https://git.kernel.org/stable/c/d3dde4c217f0c31ab0621912e682b57e677dd923 https://git.kernel.org/stable/c/0bf6cc96612bd396048f57d63f1ad454a846e39c https://git.kernel.org/stable/c/724050ae4b76e4fae05a923cb54101d792cf4404 https://git.kernel.org/stable/c/c37a27a35eadb59286c9092c49c241270c802ae2 https://git.kernel.org/stable/c/f921a58ae20852d188f70842431ce6519 • CWE-787: Out-of-bounds Write •

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

In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe() When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function gp_auxiliary_device_release() calls ida_free() and kfree(aux_device_wrapper) to free memory. We should't call them again in the error handling path. Fix this by skipping the redundant cleanup functions. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: microchip: pci1xxxx: corrige double free en el manejo de errores de gp_aux_bus_probe() Cuando auxiliar_device_add() devuelve error y luego llama a auxiliar_device_uninit(), la función de devolución de llamada gp_auxiliary_device_release() llama a ida_free( ) y kfree(aux_device_wrapper) para liberar memoria. No deberíamos volver a llamarlos en la ruta de manejo de errores. Solucione este problema omitiendo las funciones de limpieza redundantes. • https://git.kernel.org/stable/c/393fc2f5948fd340d016a9557eea6e1ac2f6c60c https://git.kernel.org/stable/c/34ae447b138680b5ed3660f7d935ff3faf88ba1a https://git.kernel.org/stable/c/86c9713602f786f441630c4ee02891987f8618b9 https://git.kernel.org/stable/c/1efe551982297924d05a367aa2b6ec3d275d5742 https://git.kernel.org/stable/c/086c6cbcc563c81d55257f9b27e14faf1d0963d3 •

CVSS: 7.5EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock. Billy Jheng Bing-Jhong reported a race between __unix_gc() and queue_oob(). __unix_gc() tries to garbage-collect close()d inflight sockets, and then if the socket has MSG_OOB in unix_sk(sk)->oob_skb, GC will drop the reference and set NULL to it locklessly. However, the peer socket still can send MSG_OOB message and queue_oob() can update unix_sk(sk)->oob_skb concurrently, leading NULL pointer dereference. [0] To fix the issue, let's update unix_sk(sk)->oob_skb under the sk_receive_queue's lock and take it everywhere we touch oob_skb. Note that we defer kfree_skb() in manage_oob() to silence lockdep false-positive (See [1]). [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page PGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events delayed_fput RIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847) Code: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc RSP: 0018:ffffc900001bfd48 EFLAGS: 00000002 RAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9 RDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00 RBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00 R13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80 FS: 0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> unix_release_sock (net/unix/af_unix.c:654) unix_release (net/unix/af_unix.c:1050) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:423) delayed_fput (fs/file_table.c:444 (discriminator 3)) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416) kthread (kernel/kthread.c:388) ret_from_fork (arch/x86/kernel/process.c:153) ret_from_fork_asm (arch/x86/entry/entry_64.S:257) </TASK> Modules linked in: CR2: 0000000000000008 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: af_unix: actualice unix_sk(sk)-&gt;oob_skb bajo el bloqueo sk_receive_queue. Billy Jheng Bing-Jhong informó de una ejecución entre __unix_gc() y queue_oob(). __unix_gc() intenta recolectar basura de sockets en vuelo close()d, y luego, si el socket tiene MSG_OOB en unix_sk(sk)-&gt;oob_skb, GC eliminará la referencia y establecerá NULL sin bloqueo. • https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668 https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276 https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140 https://git.kernel.org/stable/c/518a994aa0b87d96f1bc6678a7035df5d1fcd7a1 https://git.kernel.org/stable/c/4bf6964451c3cb411fbaa1ae8b214b3d97a59bf1 https://git.kernel.org/stable/c/d59ae9314b97e01c76a4171472441e557 • CWE-476: NULL Pointer Dereference •