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: 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: 5.5EPSS: 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 • CWE-476: NULL Pointer Dereference •
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 •