1. 22 Aug, 2023 1 commit
    • Andrey Skvortsov's avatar
      clk: Fix slab-out-of-bounds error in devm_clk_release() · 66fbfb35
      Andrey Skvortsov authored
      Problem can be reproduced by unloading snd_soc_simple_card, because in
      devm_get_clk_from_child() devres data is allocated as `struct clk`, but
      devm_clk_release() expects devres data to be `struct devm_clk_state`.
      
      KASAN report:
       ==================================================================
       BUG: KASAN: slab-out-of-bounds in devm_clk_release+0x20/0x54
       Read of size 8 at addr ffffff800ee09688 by task (udev-worker)/287
      
       Call trace:
        dump_backtrace+0xe8/0x11c
        show_stack+0x1c/0x30
        dump_stack_lvl+0x60/0x78
        print_report+0x150/0x450
        kasan_report+0xa8/0xf0
        __asan_load8+0x78/0xa0
        devm_clk_release+0x20/0x54
        release_nodes+0x84/0x120
        devres_release_all+0x144/0x210
        device_unbind_cleanup+0x1c/0xac
        really_probe+0x2f0/0x5b0
        __driver_probe_device+0xc0/0x1f0
        driver_probe_device+0x68/0x120
        __driver_attach+0x140/0x294
        bus_for_each_dev+0xec/0x160
        driver_attach+0x38/0x44
        bus_add_driver+0x24c/0x300
        driver_register+0xf0/0x210
        __platform_driver_register+0x48/0x54
        asoc_simple_card_init+0x24/0x1000 [snd_soc_simple_card]
        do_one_initcall+0xac/0x340
        do_init_module+0xd0/0x300
        load_module+0x2ba4/0x3100
        __do_sys_init_module+0x2c8/0x300
        __arm64_sys_init_module+0x48/0x5c
        invoke_syscall+0x64/0x190
        el0_svc_common.constprop.0+0x124/0x154
        do_el0_svc+0x44/0xdc
        el0_svc+0x14/0x50
        el0t_64_sync_handler+0xec/0x11c
        el0t_64_sync+0x14c/0x150
      
       Allocated by task 287:
        kasan_save_stack+0x38/0x60
        kasan_set_track+0x28/0x40
        kasan_save_alloc_info+0x20/0x30
        __kasan_kmalloc+0xac/0xb0
        __kmalloc_node_track_caller+0x6c/0x1c4
        __devres_alloc_node+0x44/0xb4
        devm_get_clk_from_child+0x44/0xa0
        asoc_simple_parse_clk+0x1b8/0x1dc [snd_soc_simple_card_utils]
        simple_parse_node.isra.0+0x1ec/0x230 [snd_soc_simple_card]
        simple_dai_link_of+0x1bc/0x334 [snd_soc_simple_card]
        __simple_for_each_link+0x2ec/0x320 [snd_soc_simple_card]
        asoc_simple_probe+0x468/0x4dc [snd_soc_simple_card]
        platform_probe+0x90/0xf0
        really_probe+0x118/0x5b0
        __driver_probe_device+0xc0/0x1f0
        driver_probe_device+0x68/0x120
        __driver_attach+0x140/0x294
        bus_for_each_dev+0xec/0x160
        driver_attach+0x38/0x44
        bus_add_driver+0x24c/0x300
        driver_register+0xf0/0x210
        __platform_driver_register+0x48/0x54
        asoc_simple_card_init+0x24/0x1000 [snd_soc_simple_card]
        do_one_initcall+0xac/0x340
        do_init_module+0xd0/0x300
        load_module+0x2ba4/0x3100
        __do_sys_init_module+0x2c8/0x300
        __arm64_sys_init_module+0x48/0x5c
        invoke_syscall+0x64/0x190
        el0_svc_common.constprop.0+0x124/0x154
        do_el0_svc+0x44/0xdc
        el0_svc+0x14/0x50
        el0t_64_sync_handler+0xec/0x11c
        el0t_64_sync+0x14c/0x150
      
       The buggy address belongs to the object at ffffff800ee09600
        which belongs to the cache kmalloc-256 of size 256
       The buggy address is located 136 bytes inside of
        256-byte region [ffffff800ee09600, ffffff800ee09700)
      
       The buggy address belongs to the physical page:
       page:000000002d97303b refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4ee08
       head:000000002d97303b order:1 compound_mapcount:0 compound_pincount:0
       flags: 0x10200(slab|head|zone=0)
       raw: 0000000000010200 0000000000000000 dead000000000122 ffffff8002c02480
       raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
        ffffff800ee09580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffffff800ee09600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       >ffffff800ee09680: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                             ^
        ffffff800ee09700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
        ffffff800ee09780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ==================================================================
      
      Fixes: abae8e57 ("clk: generalize devm_clk_get() a bit")
      Signed-off-by: default avatarAndrey Skvortsov <andrej.skvortzov@gmail.com>
      Link: https://lore.kernel.org/r/20230805084847.3110586-1-andrej.skvortzov@gmail.comSigned-off-by: default avatarStephen Boyd <sboyd@kernel.org>
      66fbfb35
  2. 05 Aug, 2023 2 commits
  3. 26 Jul, 2023 1 commit
  4. 19 Jul, 2023 3 commits
  5. 11 Jul, 2023 1 commit
    • Dmitry Rokosov's avatar
      clk: meson: change usleep_range() to udelay() for atomic context · 6e2acbfe
      Dmitry Rokosov authored
      The function meson_clk_pll_enable() can be invoked under the enable_lock
      spinlock from the clk core logic, which risks a kernel panic during the
      usleep_range() call:
      
         BUG: scheduling while atomic: kworker/u4:2/36/0x00000002
         Modules linked in: g_ffs usb_f_fs libcomposite
         CPU: 1 PID: 36 Comm: kworker/u4:2 Not tainted 6.4.0-rc5 #273
         Workqueue: events_unbound async_run_entry_fn
         Call trace:
          dump_backtrace+0x9c/0x128
          show_stack+0x20/0x38
          dump_stack_lvl+0x48/0x60
          dump_stack+0x18/0x28
          __schedule_bug+0x58/0x78
          __schedule+0x828/0xa88
          schedule+0x64/0xd8
          schedule_hrtimeout_range_clock+0xd0/0x208
          schedule_hrtimeout_range+0x1c/0x30
          usleep_range_state+0x6c/0xa8
          meson_clk_pll_enable+0x1f4/0x310
          clk_core_enable+0x78/0x200
          clk_core_enable+0x58/0x200
          clk_core_enable+0x58/0x200
          clk_core_enable+0x58/0x200
          clk_enable+0x34/0x60
      
      So it is required to use the udelay() function instead of usleep_range()
      for the atomic context safety.
      
      Fixes: b6ec400a ("clk: meson: introduce new pll power-on sequence for A1 SoC family")
      Reported-by: default avatarJan Dakinevich <yvdakinevich@sberdevices.ru>
      Signed-off-by: default avatarDmitry Rokosov <ddrokosov@sberdevices.ru>
      Link: https://lore.kernel.org/r/20230704215404.11533-1-ddrokosov@sberdevices.ruSigned-off-by: default avatarJerome Brunet <jbrunet@baylibre.com>
      6e2acbfe
  6. 09 Jul, 2023 10 commits
  7. 08 Jul, 2023 22 commits