CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52864 – platform/x86: wmi: Fix opening of char device
https://notcve.org/view.php?id=CVE-2023-52864
In the Linux kernel, the following vulnerability has been resolved: platform/x86: wmi: Fix opening of char device Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->private_data, which means that private_data will not be NULL when wmi_char_open() is called. This might cause memory corruption should wmi_char_open() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmi_free_devices(). Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using container_of(). This also avoids wmi_char_open() picking a wrong WMI device bound to a driver with the same name as the original driver. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: plataforma/x86: wmi: corrige la apertura del dispositivo char. Desde la confirmación fa1f68db6ca7 ("drivers: misc: pasar el puntero del dispositivo misc a través de datos privados del archivo"), el dispositivo misc almacena un puntero a sí mismo en su interior. filp->private_data, lo que significa que private_data no será NULL cuando se llame a wmi_char_open(). • https://git.kernel.org/stable/c/44b6b7661132b1b0e5fd3147ded66f1e4a817ca9 https://git.kernel.org/stable/c/cf098e937dd125c0317a0d6f261ac2a950a233d6 https://git.kernel.org/stable/c/9fb0eed09e1470cd4021ff52b2b9dfcbcee4c203 https://git.kernel.org/stable/c/d426a2955e45a95b2282764105fcfb110a540453 https://git.kernel.org/stable/c/e0bf076b734a2fab92d8fddc2b8b03462eee7097 https://git.kernel.org/stable/c/44a96796d25809502c75771d40ee693c2e44724e https://git.kernel.org/stable/c/36d85fa7ae0d6be651c1a745191fa7ef055db43e https://git.kernel.org/stable/c/fb7b06b59c6887659c6ed0ecd3110835e • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52855 – usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
https://notcve.org/view.php?id=CVE-2023-52855
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. • https://git.kernel.org/stable/c/33ad261aa62be02f0cedeb4d5735cc726de84a3f https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72 https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6 https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001 https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790 https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82 •
CVSS: -EPSS: 0%CPEs: 13EXPL: 0CVE-2023-52854 – padata: Fix refcnt handling in padata_free_shell()
https://notcve.org/view.php?id=CVE-2023-52854
In the Linux kernel, the following vulnerability has been resolved: padata: Fix refcnt handling in padata_free_shell() In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model: Suppose there's a user of padata named `user_function` that adheres to the padata requirement of calling `padata_free_shell` after `serial()` has been invoked, as demonstrated in the following code: ```c struct request { struct padata_priv padata; struct completion *done; }; void parallel(struct padata_priv *padata) { do_something(); } void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done); } void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell(); } ``` In the corresponding padata.c file, there's the following code: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Because of the high system load and the accumulation of unexecuted softirq at this moment, `local_bh_enable()` in padata takes longer to execute than usual. Subsequently, when accessing `pd->refcnt`, `pd` has already been released by `padata_free_shell()`, resulting in a UAF issue with `pd->refcnt`. The fix is straightforward: add `refcount_dec_and_test` before calling `padata_free_pd` in `padata_free_shell`. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: corrige el manejo de refcnt en padata_free_shell(). • https://git.kernel.org/stable/c/07928d9bfc81640bab36f5190e8725894d93b659 https://git.kernel.org/stable/c/13721e447acc2b82c19cf72e9e6c4291c77693ed https://git.kernel.org/stable/c/7a2ccb65f90168edc2348495bb56093c466ffa39 https://git.kernel.org/stable/c/928cf3d733c4efc221e1a78b14cb2ee066627260 https://git.kernel.org/stable/c/c9da8ee1491719001a444f4af688b75e72b58418 https://git.kernel.org/stable/c/dc34710a7aba5207e7cb99d11588c04535b3c53d https://git.kernel.org/stable/c/5fefc9b3e3584a1ce98da27c38e1b8dda1939d74 https://git.kernel.org/stable/c/26daf8e6515c2dcd25d235468420b9f46 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52853 – hid: cp2112: Fix duplicate workqueue initialization
https://notcve.org/view.php?id=CVE-2023-52853
In the Linux kernel, the following vulnerability has been resolved: hid: cp2112: Fix duplicate workqueue initialization Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hid: cp2112: corrige la inicialización duplicada de la cola de trabajo. Anteriormente, el controlador cp2112 llamaba INIT_DELAYED_WORK dentro de cp2112_gpio_irq_startup, lo que generaba inicializaciones duplicadas de la cola de trabajo en inicios IRQ posteriores después de una solicitud inicial. Esto resultó en una advertencia en set_work_data en workqueue.c, así como en una rara desreferencia NULL dentro de process_one_work en workqueue.c. • https://git.kernel.org/stable/c/13de9cca514ed63604263cad87ca8cb36e9b6489 https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6 https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819 https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38 https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592 https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01f •
CVSS: 5.2EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52847 – media: bttv: fix use after free error due to btv->timeout timer
https://notcve.org/view.php?id=CVE-2023-52847
In the Linux kernel, the following vulnerability has been resolved: media: bttv: fix use after free error due to btv->timeout timer There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug. This bug is found by static analysis, it may be false positive. Fix it by adding del_timer_sync invoking to the remove function. cpu0 cpu1 bttv_probe ->timer_setup ->bttv_set_dma ->mod_timer; bttv_remove ->kfree(btv); ->bttv_irq_timeout ->USE btv En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: bttv: corrección de uso después de error gratuito debido a btv->timeout timer. Puede haber alguna condición de ejecución entre la función del temporizador bttv_irq_timeout y bttv_remove. El temporizador está configurado en la sonda y no hay ninguna operación timer_delete en la función de eliminación. • https://git.kernel.org/stable/c/162e6376ac58440beb6a2d2ee294f5d88ea58dd1 https://git.kernel.org/stable/c/bbc3b8dd2cb7817e703f112d988e4f4728f0f2a9 https://git.kernel.org/stable/c/b35fdade92c5058a5e727e233fe263b828de2c9a https://git.kernel.org/stable/c/2f3d9198cdae1cb079ec8652f4defacd481eab2b https://git.kernel.org/stable/c/51c94256a83fe4e17406c66ff3e1ad7d242d8574 https://git.kernel.org/stable/c/20568d06f6069cb835e05eed432edf962645d226 https://git.kernel.org/stable/c/1871014d6ef4812ad11ef7d838d73ce09d632267 https://git.kernel.org/stable/c/847599fffa528b2cdec4e21b6bf7586da • CWE-416: Use After Free •