CVSS: 5.3EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35916 – dma-buf: Fix NULL pointer dereference in sanitycheck()
https://notcve.org/view.php?id=CVE-2024-35916
In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix NULL pointer dereference in sanitycheck() If due to a memory allocation failure mock_chain() returns NULL, it is passed to dma_fence_enable_sw_signaling() resulting in NULL pointer dereference there. Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: corrige la desreferencia del puntero NULL en sanitycheck(). Si debido a un error en la asignación de memoria, mock_chain() devuelve NULL, se pasa a dma_fence_enable_sw_signaling(), lo que genera una desreferencia del puntero NULL allí. . Llame a dma_fence_enable_sw_signaling() solo si mock_chain() tiene éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/d62c43a953ce02d54521ec06217d0c2ed6d489af https://git.kernel.org/stable/c/0336995512cdab0c65e99e4cdd47c4606debe14e https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c https://git.kernel.org/stable/c/eabf131cba1db12005a68378305f13b9090a7a6b https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35915 – nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
https://notcve.org/view.php?id=CVE-2024-35915
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_dev_up y nci_ntf_packet syzbot informó el siguiente problema de acceso al valor uninit [1][2]: nci_rx_work() analiza y procesa el paquete recibido. Cuando la longitud del payload es cero, cada controlador de tipo de mensaje lee el payload no inicializado y KMSAN detecta este problema. • https://git.kernel.org/stable/c/6a2968aaf50c7a22fced77a5e24aa636281efca8 https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240 https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16 https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f600 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35912 – wifi: iwlwifi: mvm: rfi: fix potential response leaks
https://notcve.org/view.php?id=CVE-2024-35912
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential response leaks If the rx payload length check fails, or if kmemdup() fails, we still need to free the command response. Fix that. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: mvm: rfi: corrige posibles fugas de respuesta Si falla la verificación de la longitud de la payload de rx, o si falla kmemdup(), aún necesitamos liberar la respuesta del comando. Arregla eso. • https://git.kernel.org/stable/c/21254908cbe995a3982a23da32c30d1b43467043 https://git.kernel.org/stable/c/28db0ae86cb91a4ab0e855cff779daead936b7d5 https://git.kernel.org/stable/c/99a75d75007421d8e08ba139e24f77395cd08f62 https://git.kernel.org/stable/c/c0a40f2f8eba07416f695ffe2011bf3f8b0b6dc8 https://git.kernel.org/stable/c/f7f0e784894dfcb265f0f9fa499103b0ca7eabde https://git.kernel.org/stable/c/06a093807eb7b5c5b29b6cff49f8174a4e702341 https://access.redhat.com/security/cve/CVE-2024-35912 https://bugzilla.redhat.com/show_bug.cgi?id=2281636 •
CVSS: 5.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35910 – tcp: properly terminate timers for kernel sockets
https://notcve.org/view.php?id=CVE-2024-35910
In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns. For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns. This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler. Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held. It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code) We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: termina correctamente los temporizadores para los sockets del kernel. Recibimos varios informes de syzbot sobre los temporizadores tcp que se activan después de que se han desmantelado las redes correspondientes. Afortunadamente, Josef Bacik pudo provocar el problema con más frecuencia y pudo probar un parche que escribí hace dos años. Cuando los sockets TCP están cerrados, llamamos a inet_csk_clear_xmit_timers() para "detener" los temporizadores. • https://git.kernel.org/stable/c/8a68173691f036613e3d4e6bf8dc129d4a7bf383 https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50 https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810 https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4 https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87 https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35909 – net: wwan: t7xx: Split 64bit accesses to fix alignment issues
https://notcve.org/view.php?id=CVE-2024-35909
In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Split 64bit accesses to fix alignment issues Some of the registers are aligned on a 32bit boundary, causing alignment faults on 64bit platforms. Unable to handle kernel paging request at virtual address ffffffc084a1d004 Mem abort info: ESR = 0x0000000096000061 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment fault Data abort info: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Internal error: Oops: 0000000096000061 [#1] SMP Modules linked in: mtk_t7xx(+) qcserial pppoe ppp_async option nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) iwlwifi(O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm cdc_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 geniv des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys trusted CPU: 3 PID: 5266 Comm: kworker/u9:1 Tainted: G O 6.6.22 #0 Hardware name: Bananapi BPI-R4 (DT) Workqueue: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr : t7xx_cldma_start+0xac/0x13c [mtk_t7xx] sp : ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 0000000000000001 x19: ffffff80c814b080 x18: 0000000000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffffff80ca1ef6b4 x7 : ffffff80c814b818 x6 : 0000000000000018 x5 : 0000000000000870 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000010a947000 x1 : ffffffc084a1d004 x0 : ffffffc084a1d004 Call trace: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] process_one_work+0x154/0x2a0 worker_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Code: f9400800 91001000 8b214001 d50332bf (f9000022) ---[ end trace 0000000000000000 ]--- The inclusion of io-64-nonatomic-lo-hi.h indicates that all 64bit accesses can be replaced by pairs of nonatomic 32bit access. Fix alignment by forcing all accesses to be 32bit on 64bit platforms. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: wwan: t7xx: Accesos divididos de 64 bits para solucionar problemas de alineación Algunos de los registros están alineados en un límite de 32 bits, provocando fallos de alineación en plataformas de 64 bits. No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffffc084a1d004 Información de cancelación de memoria: ESR = 0x0000000096000061 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alineación falla Información de cancelación de datos: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 tabla de intercambio: 4k páginas, VA de 39 bits, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Error interno: Vaya: 0000000096000061 [#1] Módulos SMP vinculados en: mtk_t7xx(+) qcserial pppoe ppp_async opción nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 n ft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm c_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys CPU confiable: 3 PID: 5266 Comm: kworker/u9:1 ted: GO 6.6.22 #0 Nombre del hardware: Bananapi BPI -R4 (DT) Cola de trabajo: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr: _cldma_start+0xac/0x13c [mtk_t7xx] sp: ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 00000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c 0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 00000000000000001 x19: ffffff80c814b080 x18: 00000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 00000000000000000 x10: 0000000000000000 x9: 000 0000000000000 x8: ffffff80ca1ef6b4 x7: ffffff80c814b818 x6: 0000000000000018 x5: 0000000000000870 x4: 0000000000000000 x3: 0000000000000000 0 x2: 000000010a947000 x1: ffffffc084a1d004 x0: ffffffc084a1d004 Rastreo de llamadas: t7xx_cldma_hw_set_start_addr +0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] Process_one_work+0x154/0x2a0 Workers_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Código: f9400800 9 1001000 8b214001 d50332bf (f9000022) ---[ final de seguimiento 0000000000000000 ]--- La inclusión de io-64-nonatomic-lo-hi.h indica que todos los accesos de 64 bits pueden ser reemplazados por pares de accesos no atómicos de 32 bits. Corrija la alineación obligando a que todos los accesos sean de 32 bits en plataformas de 64 bits. • https://git.kernel.org/stable/c/39d439047f1dc88f98b755d6f3a53a4ef8f0de21 https://git.kernel.org/stable/c/beaf0e7996b79e06ccc2bdcb4442fbaeccc31200 https://git.kernel.org/stable/c/2e22c9cb618716b8e557fe17c3d4958171288082 https://git.kernel.org/stable/c/b4fdb3c197e35f655b2d9b6759ce29440eacdfda https://git.kernel.org/stable/c/7d5a7dd5a35876f0ecc286f3602a88887a788217 •