CVE-2023-52516

In the Linux kernel, the following vulnerability has been resolved:

dma-debug: dont call __dma_entry_alloc_check_leak() under free_entries_lock

__dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock.

Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we dont acquire serial consoles port->lock under it.

Trimmed-down lockdep splat:

The existing dependency chain (in reverse order) is:

           -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80
    dma_entry_alloc+0x38/0x110
    debug_dma_map_page+0x60/0xf8
    dma_map_page_attrs+0x1e0/0x230
    dma_map_single_attrs.constprop.0+0x6c/0xc8
    geni_se_rx_dma_prep+0x40/0xcc
    qcom_geni_serial_isr+0x310/0x510
    __handle_irq_event_percpu+0x110/0x244
    handle_irq_event_percpu+0x20/0x54
    handle_irq_event+0x50/0x88
    handle_fasteoi_irq+0xa4/0xcc
    handle_irq_desc+0x28/0x40
    generic_handle_domain_irq+0x24/0x30
    gic_handle_irq+0xc4/0x148
    do_interrupt_handler+0xa4/0xb0
    el1_interrupt+0x34/0x64
    el1h_64_irq_handler+0x18/0x24
    el1h_64_irq+0x64/0x68
    arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24
    ...

           -> #1 (&port_lock_key){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80
    qcom_geni_serial_console_write+0x184/0x1dc
    console_flush_all+0x344/0x454
    console_unlock+0x94/0xf0
    vprintk_emit+0x238/0x24c
    vprintk_default+0x3c/0x48
    vprintk+0xb4/0xbc
    _printk+0x68/0x90
    register_console+0x230/0x38c
    uart_add_one_port+0x338/0x494
    qcom_geni_serial_probe+0x390/0x424
    platform_probe+0x70/0xc0
    really_probe+0x148/0x280
    __driver_probe_device+0xfc/0x114
    driver_probe_device+0x44/0x100
    __device_attach_driver+0x64/0xdc
    bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140
    device_initial_probe+0x1c/0x28
    bus_probe_device+0x44/0xb0
    device_add+0x538/0x668
    of_device_add+0x44/0x50
    of_platform_device_create_pdata+0x94/0xc8
    of_platform_bus_create+0x270/0x304
    of_platform_populate+0xac/0xc4
    devm_of_platform_populate+0x60/0xac
    geni_se_probe+0x154/0x160
    platform_probe+0x70/0xc0
    ...

           -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c
    lock_acquire+0x234/0x284
    console_flush_all+0x330/0x454
    console_unlock+0x94/0xf0
    vprintk_emit+0x238/0x24c
    vprintk_default+0x3c/0x48
    vprintk+0xb4/0xbc
    _printk+0x68/0x90
    dma_entry_alloc+0xb4/0x110
    debug_dma_map_sg+0xdc/0x2f8
    __dma_map_sg_attrs+0xac/0xe4
    dma_map_sgtable+0x30/0x4c
    get_pages+0x1d4/0x1e4 [msm]
    msm_gem_pin_pages_locked+0x38/0xac [msm]
    msm_gem_pin_vma_locked+0x58/0x88 [msm]
    msm_ioctl_gem_submit+0xde4/0x13ac [msm]
    drm_ioctl_kernel+0xe0/0x15c
    drm_ioctl+0x2e8/0x3f4
    vfs_ioctl+0x30/0x50
    ...

Chain exists of: console_owner –> &port_lock_key –> free_entries_lock

Possible unsafe locking scenario:

    CPU0                    CPU1
    ----                    ----

lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner);

            *** DEADLOCK ***

Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol —truncated—

Weakness

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Affected Software

Extended Description

Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.

Potential Mitigations

Related Attack Patterns

• https://cwe.mitre.org/data/definitions/25.html
• https://cwe.mitre.org/data/definitions/26.html
• https://cwe.mitre.org/data/definitions/27.html

References

• https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c
• https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab
• https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae
• https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1
• https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3
• https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c
• https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab
• https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae
• https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1
• https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3