CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52863 – hwmon: (axi-fan-control) Fix possible NULL pointer dereference
https://notcve.org/view.php?id=CVE-2023-52863
In the Linux kernel, the following vulnerability has been resolved: hwmon: (axi-fan-control) Fix possible NULL pointer dereference axi_fan_control_irq_handler(), dependent on the private axi_fan_control_data structure, might be called before the hwmon device is registered. That will cause an "Unable to handle kernel NULL pointer dereference" error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (axi-fan-control) Se corrigió la posible desreferencia del puntero NULL. Se podría llamar a axi_fan_control_irq_handler(), dependiente de la estructura privada axi_fan_control_data, antes de que se registre el dispositivo hwmon. Esto provocará el error "No se puede manejar la desreferencia del puntero NULL del kernel". • https://git.kernel.org/stable/c/8412b410fa5e1e494a0fec84c3c462d49870d3f5 https://git.kernel.org/stable/c/7d870088db4863c514a7f8751cd593751983029a https://git.kernel.org/stable/c/b3e7eb23a6e97642ff3190431c06475d9ca1e062 https://git.kernel.org/stable/c/33de53a2706066d526173dc743faf43d92c62105 https://git.kernel.org/stable/c/f62b8969847850ba7596cb145cc47c65ea57dae0 https://git.kernel.org/stable/c/c49f14cc1bb12c625a1c572e8a95b6adefd4d8eb https://git.kernel.org/stable/c/2a5b3370a1d9750eca325292e291c8c7cb8cf2e0 •
CVSS: 6.2EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52858 – clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data
https://notcve.org/view.php?id=CVE-2023-52858
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: mediatek: clk-mt7629: Agregar verificación para mtk_alloc_clk_data. Agregue la verificación para el valor de retorno de mtk_alloc_clk_data() para evitar la desreferencia al puntero NULL. • https://git.kernel.org/stable/c/3b5e748615e714711220b2a95d19bd25a037db09 https://git.kernel.org/stable/c/e8ae4b49dd9cfde69d8de8c0c0cd7cf1b004482e https://git.kernel.org/stable/c/4f861b63945e076f9f003a5fad958174096df1ee https://git.kernel.org/stable/c/e964d21dc034b650d719c4ea39564bec72b42f94 https://git.kernel.org/stable/c/a836efc21ef04608333d6d05753e558ebd1f85d0 https://git.kernel.org/stable/c/1d89430fc3158f872d492f1b88d07262f48290c0 https://git.kernel.org/stable/c/5fbea47eebff5daeca7d918c99289bcd3ae4dc8d https://git.kernel.org/stable/c/2befa515c1bb6cdd33c262b909d93d197 • CWE-476: NULL Pointer Dereference •
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 •