CVSS: 6.0EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26894 – ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
https://notcve.org/view.php?id=CVE-2024-26894
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit() After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak: unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0 [<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0 [<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 [<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470 [<ffffffff99b231f6>] kernel_init+0x16/0x1b0 [<ffffffff99042e6d>] ret_from_fork+0x2d/0x50 Fix this by freeing the CPU idle device after unregistering it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: procesador_idle: corrige la pérdida de memoria en acpi_processor_power_exit() Después de cancelar el registro del dispositivo de CPU inactivo, la memoria asociada con él no se libera, lo que genera una pérdida de memoria: objeto sin referencia 0xffff896282f6c000 (tamaño 1024): comunicación "swapper/0", pid 1, santiamén 4294893170 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ........... ..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc 8836a742): [] kmalloc_trace+ 0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] realmente_probe+0xe2/0x480 [] __driver_probe_device+ 0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+ 0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+ 0x2d/0x50 Solucione este problema liberando el dispositivo de CPU inactivo después de cancelar su registro. • https://git.kernel.org/stable/c/3d339dcbb56d8d70c1b959aff87d74adc3a84eea https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5 https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2 https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8 https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334 • CWE-401: Missing Release of Memory after Effective Lifetime CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26893 – firmware: arm_scmi: Fix double free in SMC transport cleanup path
https://notcve.org/view.php?id=CVE-2024-26893
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in SMC transport cleanup path When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scmi: Corrección de doble liberación en la ruta de limpieza del transporte SMC Cuando el código SCMI genérico destruye un canal, llama a la función de devolución de llamada chan_free, definida por cada transporte. • https://git.kernel.org/stable/c/1dc6558062dadfabd2fb3bd885fa6e92ec7196f2 https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4 https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773 https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd •
CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26892 – wifi: mt76: mt7921e: fix use-after-free in free_irq()
https://notcve.org/view.php?id=CVE-2024-26892
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921e: fix use-after-free in free_irq() From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test to make sure the shared irq handler should be able to handle the unexpected event after deregistration. For this case, let's apply MT76_REMOVED flag to indicate the device was removed and do not run into the resource access anymore. BUG: KASAN: use-after-free in mt7921_irq_handler+0xd8/0x100 [mt7921e] Read of size 8 at addr ffff88824a7d3b78 by task rmmod/11115 CPU: 28 PID: 11115 Comm: rmmod Tainted: G W L 5.17.0 #10 Hardware name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I EDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x1f/0x190 ? mt7921_irq_handler+0xd8/0x100 [mt7921e] ? mt7921_irq_handler+0xd8/0x100 [mt7921e] kasan_report.cold+0x7f/0x11b ? • https://git.kernel.org/stable/c/9270270d62191b7549296721e8d5f3dc0df01563 https://git.kernel.org/stable/c/a76eaaaafd8b408238d7865bbbbd311f08988f3d https://git.kernel.org/stable/c/95e41ac30a0d0b3637f0b3c93235a7a107a2fb7f https://git.kernel.org/stable/c/c7dd42fbebcfb02bef070fd48f774d6412d0b49d https://git.kernel.org/stable/c/bfe1adf1606f76c180324e53b130f0e76d5cc6c3 https://git.kernel.org/stable/c/bfeaef901194c5923ce3330272786eff2fac513a https://git.kernel.org/stable/c/c957280ef6ab6bdf559a91ae693a6b34310697e3 https://access.redhat.com/security/cve/CVE-2024-26892 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26891 – iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected
https://notcve.org/view.php?id=CVE-2024-26891
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected For those endpoint devices connect to system via hotplug capable ports, users could request a hot reset to the device by flapping device's link through setting the slot's link control register, as pciehp_ist() DLLSC interrupt sequence response, pciehp will unload the device driver and then power it off. thus cause an IOMMU device-TLB invalidation (Intel VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence target device to be sent and deadly loop to retry that request after ITE fault triggered in interrupt context. That would cause following continuous hard lockup warning and system hang [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822623] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) knlGS:0000000000000000 [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0 [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 4223.822628] PKRU: 55555554 [ 4223.822628] Call Trace: [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822629] intel_iommu_release_device+0x1f/0x30 [ 4223.822629] iommu_release_device+0x33/0x60 [ 4223.822629] iommu_bus_notifier+0x7f/0x90 [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 [ 4223.822630] device_del+0x2e5/0x420 [ 4223.822630] pci_remove_bus_device+0x70/0x110 [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822631] pciehp_disable_slot+0x6b/0x100 [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822631] pciehp_ist+0x176/0x180 [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822632] irq_thread_fn+0x19/0x50 [ 4223.822632] irq_thread+0x104/0x190 [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822633] kthread+0x114/0x130 [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 [ 4223.822633] ret_from_fork+0x1f/0x30 [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822634] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822634] Call Trace: [ 4223.822634] <NMI> [ 4223.822635] dump_stack+0x6d/0x88 [ 4223.822635] panic+0x101/0x2d0 [ 4223.822635] ? • https://git.kernel.org/stable/c/6f7db75e1c469057fe7588ed959328ead771ccc7 https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85 https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554 https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062 https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868 https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05 https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778 •
CVSS: 6.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26890 – Bluetooth: btrtl: fix out of bounds memory access
https://notcve.org/view.php?id=CVE-2024-26890
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: fix out of bounds memory access The problem is detected by KASAN. btrtl driver uses private hci data to store 'struct btrealtek_data'. If btrtl driver is used with btusb, then memory for private hci data is allocated in btusb. But no private data is allocated after hci_dev, when btrtl is used with hci_h5. This commit adds memory allocation for hci_h5 case. ================================================================== BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl] Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76 Hardware name: Pine64 PinePhone (1.2) (DT) Workqueue: hci0 hci_power_on [bluetooth] Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_store8+0x9c/0xc0 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 53: kasan_save_stack+0x3c/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x68/0x78 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x1b4/0x3b0 hci_alloc_dev_priv+0x28/0xa58 [bluetooth] hci_uart_register_device+0x118/0x4f8 [hci_uart] h5_serdev_probe+0xf4/0x178 [hci_uart] serdev_drv_probe+0x54/0xa0 really_probe+0x254/0x588 __driver_probe_device+0xc4/0x210 driver_probe_device+0x64/0x160 __driver_attach_async_helper+0x88/0x158 async_run_entry_fn+0xd0/0x388 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x33c/0x960 queue_work_on+0x98/0xc0 hci_recv_frame+0xc8/0x1e8 [bluetooth] h5_complete_rx_pkt+0x2c8/0x800 [hci_uart] h5_rx_payload+0x98/0xb8 [hci_uart] h5_recv+0x158/0x3d8 [hci_uart] hci_uart_receive_buf+0xa0/0xe8 [hci_uart] ttyport_receive_buf+0xac/0x178 flush_to_ldisc+0x130/0x2c8 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Second to last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x788/0x960 queue_work_on+0x98/0xc0 __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth] __hci_cmd_sync+0x24/0x38 [bluetooth] btrtl_initialize+0x760/0x958 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 ================================================================== En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: Bluetooth: btrtl: arreglar acceso a memoria fuera de los límites El problema es detectado por KASAN. El controlador btrtl utiliza datos privados de hci para almacenar 'struct btrealtek_data'. Si se utiliza el controlador btrtl con btusb, entonces la memoria para los datos privados de hci se asigna en btusb. Pero no se asignan datos privados después de hci_dev, cuando se usa btrtl con hci_h5. • https://git.kernel.org/stable/c/5b355944b19011011dd3fd4187444c5ff1d76ad2 https://git.kernel.org/stable/c/dd163fa34c483f1674aa2510accce11a224f649e https://git.kernel.org/stable/c/2f232bc389a4f5943c40733582f9edf77b89e499 https://git.kernel.org/stable/c/0c657e641df1e77d6087688190f632cad9c0439b https://git.kernel.org/stable/c/de4e88ec58c4202efd1f02eebb4939bbf6945358 https://access.redhat.com/security/cve/CVE-2024-26890 https://bugzilla.redhat.com/show_bug.cgi?id=2275670 • CWE-125: Out-of-bounds Read •