Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
l.org/stable/c/eff76b180751e5e55c872d17755680c3b83ba9ab - https://git.kernel.org/stable/c/8d075ede7d24f19dc817c5bd517a53f0524f9031 - https://git.kernel.org/stable/c/4eb591c47c82a6a6ad293ed108c3cb77115fbc25 - https://git.kernel.org/stable/c/417591a766b3c040c346044541ff949c0b2bb7b2
CVE ID: CVE-2022-49166 State: PUBLISHED Published: 2025-02-26T01:55:25.528Z Last Updated: 2025-05-04T08:31:24.640Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ntfs: add sanity check on allocation size ntfs_read_inode_mount invokes ntfs_malloc_nofs with zero allocation size. It triggers one BUG in the __ntfs_malloc function. Fix this by adding sanity check on ni->attr_list_size. References: - https://git.kernel.org/stable/c/bd8d7daa0e53b184a2f3c6e0d47330780d0a0650 - https://git.kernel.org/stable/c/21d490232f323ed4053eb9924615e6fea291f154 - https://git.kernel.org/stable/c/07793d2e55563124108762f4e5f811db92ffe02f - https://git.
323ed4053eb9924615e6fea291f154 - https://git.kernel.org/stable/c/07793d2e55563124108762f4e5f811db92ffe02f - https://git.kernel.org/stable/c/fe41ad8be036a3de3e4bdde709551aeb4de2fe7d - https://git.kernel.org/stable/c/b230f2d9441a34c7f483d39ab78519bcf73cc2e0 - https://git.kernel.org/stable/c/24ab2d4ef52c2dbb62a60844b87fc8872383407a - https://git.kernel.org/stable/c/115fae2c1566eacc5ad2055f72521354612e72c3 - https://git.kernel.org/stable/c/c641087d381a08363e5f14179bc6b0a23eca7c47 - https://git.kernel.org/stable/c/714fbf2647b1a33d914edd695d4da92029c7e7c0
CVE ID: CVE-2022-49167 State: PUBLISHED Published: 2025-02-26T01:55:26.030Z Last Updated: 2025-09-03T12:58:39.199Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: do not double complete bio on errors during compressed reads I hit some weird panics while fixing up the error handling from btrfs_lookup_bio_sums(). Turns out the compression path will complete the bio we use if we set up any of the compression bios and then return an error, and then btrfs_submit_data_bio() will also call bio_endio() on the bio. Fix this by making btrfs_submit_compressed_read() responsible for calling bio_endio() on the bio if there are any err
o. Fix this by making btrfs_submit_compressed_read() responsible for calling bio_endio() on the bio if there are any errors. Currently it was only doing it if we created the compression bios, otherwise it was depending on btrfs_submit_data_bio() to do the right thing. This creates the above problem, so fix up btrfs_submit_compressed_read() to always call bio_endio() in case of an error, and then simply return from btrfs_submit_data_bio() if we had to call btrfs_submit_compressed_read(). References: - https://git.kernel.org/stable/c/4a4ceb2b990771c374d85d496a1a45255dde48e3 - https://git.kernel.org/stable/c/987b5df1d10355d377315a26e7fb6c72ded83c9f - https://git.kernel.org/stable/c/f9f15de85d74
https://git.kernel.org/stable/c/987b5df1d10355d377315a26e7fb6c72ded83c9f - https://git.kernel.org/stable/c/f9f15de85d74e7eef021af059ca53a15f041cdd8
CVE ID: CVE-2022-49168 State: PUBLISHED Published: 2025-02-26T01:55:26.532Z Last Updated: 2025-05-22T12:39:22.447Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: do not clean up repair bio if submit fails The submit helper will always run bio_endio() on the bio if it fails to submit, so cleaning up the bio just leads to a variety of use-after-free and NULL pointer dereference bugs because we race with the endio function that is cleaning up the bio. Instead just return BLK_STS_OK as the repair function has to continue to process the rest of the pages, and the endio for the repair bio will do the appropriate cleanup for th
as to continue to process the rest of the pages, and the endio for the repair bio will do the appropriate cleanup for the page that it was given. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7170875083254b51fcc5d67f96640977083f481e - https://git.kernel.org/stable/c/e76c78c48902dae6fa612749f59162bca0a79e0b - https://git.kernel.org/stable/c/d1cb11fb45ebbb1e7dfe5e9038b32ea72c184b14 - https://git.kernel.org/stable/c/8cbc3001a3264d998d6b6db3e23f935c158abd4d
CVE ID: CVE-2022-49169 State: PUBLISHED Published: 2025-02-26T01:55:27.044Z Last Updated: 2025-07-11T17:19:08.823Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: use spin_lock to avoid hang [14696.634553] task:cat state:D stack: 0 pid:1613738 ppid:1613735 flags:0x00000004 [14696.638285] Call Trace: [14696.639038] <TASK> [14696.640032] __schedule+0x302/0x930 [14696.640969] schedule+0x58/0xd0 [14696.641799] schedule_preempt_disabled+0x18/0x30 [14696.642890] __mutex_lock.constprop.0+0x2fb/0x4f0 [14696.644035] ? mod_objcg_state+0x10c/0x310 [14696.645040] ? obj_cgroup_charge+0xe1/0x170 [14696.646067] __mutex_lock_slowpath+0x13
5] ? mod_objcg_state+0x10c/0x310 [14696.645040] ? obj_cgroup_charge+0xe1/0x170 [14696.646067] __mutex_lock_slowpath+0x13/0x20 [14696.647126] mutex_lock+0x34/0x40 [14696.648070] stat_show+0x25/0x17c0 [f2fs] [14696.649218] seq_read_iter+0x120/0x4b0 [14696.650289] ? aa_file_perm+0x12a/0x500 [14696.651357] ? lru_cache_add+0x1c/0x20 [14696.652470] seq_read+0xfd/0x140 [14696.653445] full_proxy_read+0x5c/0x80 [14696.654535] vfs_read+0xa0/0x1a0 [14696.655497] ksys_read+0x67/0xe0 [14696.656502] __x64_sys_read+0x1a/0x20 [14696.657580] do_syscall_64+0x3b/0xc0 [14696.658671] entry_SYSCALL_64_after_hwframe+0x44/0xae [14696.660068] RIP: 0033:0x7efe39df1cb2 [14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS:
ALL_64_after_hwframe+0x44/0xae [14696.660068] RIP: 0033:0x7efe39df1cb2 [14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [14696.662958] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007efe39df1cb2 [14696.664757] RDX: 0000000000020000 RSI: 00007efe399df000 RDI: 0000000000000003 [14696.666542] RBP: 00007efe399df000 R08: 00007efe399de010 R09: 00007efe399de010 [14696.668363] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000 [14696.670155] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [14696.671965] </TASK> [14696.672826] task:umount state:D stack: 0 pid:1614985 ppid:1614984 flags:0x00004000 [14696.674930] Call Trace: [1
ASK> [14696.672826] task:umount state:D stack: 0 pid:1614985 ppid:1614984 flags:0x00004000 [14696.674930] Call Trace: [14696.675903] <TASK> [14696.676780] __schedule+0x302/0x930 [14696.677927] schedule+0x58/0xd0 [14696.679019] schedule_preempt_disabled+0x18/0x30 [14696.680412] __mutex_lock.constprop.0+0x2fb/0x4f0 [14696.681783] ? destroy_inode+0x65/0x80 [14696.683006] __mutex_lock_slowpath+0x13/0x20 [14696.684305] mutex_lock+0x34/0x40 [14696.685442] f2fs_destroy_stats+0x1e/0x60 [f2fs] [14696.686803] f2fs_put_super+0x158/0x390 [f2fs] [14696.688238] generic_shutdown_super+0x7a/0x120 [14696.689621] kill_block_super+0x27/0x50 [14696.690894] kill_f2fs_super+0x7f/0x100 [f2fs] [14696.692311] deacti
a/0x120 [14696.689621] kill_block_super+0x27/0x50 [14696.690894] kill_f2fs_super+0x7f/0x100 [f2fs] [14696.692311] deactivate_locked_super+0x35/0xa0 [14696.693698] deactivate_super+0x40/0x50 [14696.694985] cleanup_mnt+0x139/0x190 [14696.696209] __cleanup_mnt+0x12/0x20 [14696.697390] task_work_run+0x64/0xa0 [14696.698587] exit_to_user_mode_prepare+0x1b7/0x1c0 [14696.700053] syscall_exit_to_user_mode+0x27/0x50 [14696.701418] do_syscall_64+0x48/0xc0 [14696.702630] entry_SYSCALL_64_after_hwframe+0x44/0xae References: - https://git.kernel.org/stable/c/2eff60346e7ae1a24cd868b8fdcf58e946e7dde1 - https://git.kernel.org/stable/c/738886004bd2885ac2db0bc63b4874aa471ca87e - https://git.kernel.org/stable/
58e946e7dde1 - https://git.kernel.org/stable/c/738886004bd2885ac2db0bc63b4874aa471ca87e - https://git.kernel.org/stable/c/ec4187d45cc1c2d69fffeee5fa6aa4cb62477cfb - https://git.kernel.org/stable/c/98237fcda4a24e67b0a4498c17d5aa4ad4537bc7
CVE ID: CVE-2022-49170 State: PUBLISHED Published: 2025-02-26T01:55:27.562Z Last Updated: 2025-07-11T17:19:10.037Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on curseg->alloc_type As Wenqing Liu reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215657 - Overview UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image - Reproduce tested on kernel 5.17-rc4, 5.17-rc6 1. mkdir test_crash 2. cd test_crash 3. unzip tmp2.zip 4. mkdir mnt 5. ./single_test.sh f2fs 2 - Kernel dump [ 46.434454] loop0: detected capacity change from 0 to 131072 [
p 4. mkdir mnt 5. ./single_test.sh f2fs 2 - Kernel dump [ 46.434454] loop0: detected capacity change from 0 to 131072 [ 46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9 [ 46.738319] ================================================================================ [ 46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 [ 46.738475] index 231 is out of range for type 'unsigned int [2]' [ 46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1 [ 46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 46.738551] Call Trace: [ 46.738556] <TASK> [ 46.738563] dump_stack_lvl+0x47/0x5c [ 46.738581] ubsan_epilo
1 04/01/2014 [ 46.738551] Call Trace: [ 46.738556] <TASK> [ 46.738563] dump_stack_lvl+0x47/0x5c [ 46.738581] ubsan_epilogue+0x5/0x50 [ 46.738592] __ubsan_handle_out_of_bounds+0x68/0x80 [ 46.738604] f2fs_allocate_data_block+0xdff/0xe60 [f2fs] [ 46.738819] do_write_page+0xef/0x210 [f2fs] [ 46.738934] f2fs_do_write_node_page+0x3f/0x80 [f2fs] [ 46.739038] __write_node_page+0x2b7/0x920 [f2fs] [ 46.739162] f2fs_sync_node_pages+0x943/0xb00 [f2fs] [ 46.739293] f2fs_write_checkpoint+0x7bb/0x1030 [f2fs] [ 46.739405] kill_f2fs_super+0x125/0x150 [f2fs] [ 46.739507] deactivate_locked_super+0x60/0xc0 [ 46.739517] deactivate_super+0x70/0xb0 [ 46.739524] cleanup_mnt+0x11a/0x200 [ 46.739532] __cleanup_mnt+0x
per+0x60/0xc0 [ 46.739517] deactivate_super+0x70/0xb0 [ 46.739524] cleanup_mnt+0x11a/0x200 [ 46.739532] __cleanup_mnt+0x16/0x20 [ 46.739538] task_work_run+0x67/0xa0 [ 46.739547] exit_to_user_mode_prepare+0x18c/0x1a0 [ 46.739559] syscall_exit_to_user_mode+0x26/0x40 [ 46.739568] do_syscall_64+0x46/0xb0 [ 46.739584] entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is we missed to do sanity check on curseg->alloc_type, result in out-of-bound accessing on sbi->block_count[] array, fix it. References: - https://git.kernel.org/stable/c/498b7088db71f9707359448cd6800bbb1882f4c3 - https://git.kernel.org/stable/c/f68caedf264a95c0b02dfd0d9f92ac2637d5848a - https://git.kernel.org/stable/c/0748a0f7
c3 - https://git.kernel.org/stable/c/f68caedf264a95c0b02dfd0d9f92ac2637d5848a - https://git.kernel.org/stable/c/0748a0f7dcb9d9dddc80302d73ebcecef6782ef0 - https://git.kernel.org/stable/c/c12765e3f129b144421c80d3383df885f85ee290 - https://git.kernel.org/stable/c/f41ee8b91c00770d718be2ff4852a80017ae9ab3
CVE ID: CVE-2022-49171 State: PUBLISHED Published: 2025-02-26T01:55:28.077Z Last Updated: 2025-05-04T08:31:31.813Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: don't BUG if someone dirty pages without asking ext4 first [un]pin_user_pages_remote is dirtying pages without properly warning the file system in advance. A related race was noted by Jan Kara in 2018[1]; however, more recently instead of it being a very hard-to-hit race, it could be reliably triggered by process_vm_writev(2) which was discovered by Syzbot[2]. This is technically a bug in mm/gup.c, but arguably ext4 is fragile in that if some other kernel subsyst
d by Syzbot[2]. This is technically a bug in mm/gup.c, but arguably ext4 is fragile in that if some other kernel subsystem dirty pages without properly notifying the file system using page_mkwrite(), ext4 will BUG, while other file systems will not BUG (although data will still be lost). So instead of crashing with a BUG, issue a warning (since there may be potential data loss) and just mark the page as clean to avoid unprivileged denial of service attacks until the problem can be properly fixed. More discussion and background can be found in the thread starting at [2]. [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@go
https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com References: - https://git.kernel.org/stable/c/5db60e76edf5680ff1f3a7221036fc44b308f146 - https://git.kernel.org/stable/c/d666dfaa571465a19f014534a214c255ea33f301 - https://git.kernel.org/stable/c/0d3a6926f7e8be3c897fa46216ce13b119a9f56a - https://git.kernel.org/stable/c/5a016c053f426a73752c3b41b60b497b58694d48 - https://git.kernel.org/stable/c/330d0e44fc5a47c27df958ecdd4693a3cb1d8b81 - https://git.kernel.org/stable/c/a0856764dc1276ad2dc7891288c2e9246bf11a37 - https://git.kernel.org/stable/c/343117559ef41e992e326f7a92da1a8f254dfa8c - https://git.kernel.org/stable/c/
246bf11a37 - https://git.kernel.org/stable/c/343117559ef41e992e326f7a92da1a8f254dfa8c - https://git.kernel.org/stable/c/677c9d30e8487bee6c8e3b034070319d98f6e203 - https://git.kernel.org/stable/c/cc5095747edfb054ca2068d01af20be3fcc3634f
CVE ID: CVE-2022-49172 State: PUBLISHED Published: 2025-02-26T01:55:28.628Z Last Updated: 2025-05-04T08:31:33.041Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: parisc: Fix non-access data TLB cache flush faults When a page is not present, we get non-access data TLB faults from the fdc and fic instructions in flush_user_dcache_range_asm and flush_user_icache_range_asm. When these occur, the cache line is not invalidated and potentially we get memory corruption. The problem was hidden by the nullification of the flush instructions. These faults also affect performance. With pa8800/pa8900 processors, there will be 32 faults per
he flush instructions. These faults also affect performance. With pa8800/pa8900 processors, there will be 32 faults per 4 KB page since the cache line is 128 bytes. There will be more faults with earlier processors. The problem is fixed by using flush_cache_pages(). It does the flush using a tmp alias mapping. The flush_cache_pages() call in flush_cache_range() flushed too large a range. V2: Remove unnecessary preempt_disable() and preempt_enable() calls. References: - https://git.kernel.org/stable/c/b3d6adb3a49d82e4e557c5fc16f50c9ff731da5d - https://git.kernel.org/stable/c/ddca4b82027e2a66333dd40fab21a4beff435c7e - https://git.kernel.org/stable/c/f839e5f1cef36ce268950c387129b1bfefdaebc9
CVE ID: CVE-2022-49173 State: PUBLISHED Published: 2025-02-26T01:55:29.122Z Last Updated: 2025-05-04T08:31:34.385Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: fsi: Implement a timeout for polling status The data transfer routines must poll the status register to determine when more data can be shifted in or out. If the hardware gets into a bad state, these polling loops may never exit. Prevent this by returning an error if a timeout is exceeded. References: - https://git.kernel.org/stable/c/d4982ceb137e6ecd2b466a6de639790a148cf19a - https://git.kernel.org/stable/c/dac1438f347d3b8cf892105c94e254f29c5764de - https://git.k
e6ecd2b466a6de639790a148cf19a - https://git.kernel.org/stable/c/dac1438f347d3b8cf892105c94e254f29c5764de - https://git.kernel.org/stable/c/89b35e3f28514087d3f1e28e8f5634fbfd07c554
CVE ID: CVE-2022-49174 State: PUBLISHED Published: 2025-02-26T01:55:29.590Z Last Updated: 2025-05-04T08:31:36.036Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit In case of flex_bg feature (which is by default enabled), extents for any given inode might span across blocks from two different block group. ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the starting block group, but it fails to read it again when the extent length boundary overflows to another block group. Then in this below loop it accesses memory beyond the block group bitmap buffer_
ndary overflows to another block group. Then in this below loop it accesses memory beyond the block group bitmap buffer_head and results into a data abort. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) already++; This patch adds this functionality for checking block group boundary in ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different block group. w/o this patch, I was easily able to hit a data access abort using Power platform. <...> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters [ 74.533214] EXT4-fs (loop3): shut down r
11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters [ 74.533214] EXT4-fs (loop3): shut down requested (2) [ 74.536705] Aborting journal on device loop3-8. [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000 [ 74.703727] Faulting instruction address: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 current = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> enter ? for help
0000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> enter ? for help [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c00
0000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250 References: - https://git.kernel.org/stable/c/cd6d719534af993210306f8a13f9cb3e615f7c8d - https://git.kernel.org/stable/c/6a6beb074186a0452368a023a261c7d0eaebe838 - https://git.kernel.org/stable/c/b07eedd0222e9548ffc568ec429bb1f61d21a39c - https://git.kernel.org/stable/c/803fb0e8240cc16585a5c9df76add1dfaa781773 - https://git.kerne
8ffc568ec429bb1f61d21a39c - https://git.kernel.org/stable/c/803fb0e8240cc16585a5c9df76add1dfaa781773 - https://git.kernel.org/stable/c/bfdc502a4a4c058bf4cbb1df0c297761d528f54d
CVE ID: CVE-2022-49175 State: PUBLISHED Published: 2025-02-26T01:55:30.087Z Last Updated: 2025-05-04T08:31:37.398Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PM: core: keep irq flags in device_pm_check_callbacks() The function device_pm_check_callbacks() can be called under the spin lock (in the reported case it happens from genpd_add_device() -> dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes. However this function uncoditionally uses spin_lock_irq() / spin_unlock_irq(), thus not preserving the CPU flags. Use the irqsave/irqrestore instead. The backtrace for the reference: [ 2.752010] ------------[ c
eserving the CPU flags. Use the irqsave/irqrestore instead. The backtrace for the reference: [ 2.752010] ------------[ cut here ]------------ [ 2.756769] raw_local_irq_restore() called with IRQs enabled [ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50 [ 2.772338] Modules linked in: [ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684 [ 2.781384] Freeing initrd memory: 46024K [ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50 [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50 [ 2.785846] sp : ffff80000805b7d0 [ 2.785847]
s_irq_restore+0x34/0x50 [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50 [ 2.785846] sp : ffff80000805b7d0 [ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002 [ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800 [ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00 [ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff [ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7 [ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8 [ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0 [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40
860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0 [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0 [ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000 [ 2.889774] Call trace: [ 2.892290] warn_bogus_irq_restore+0x34/0x50 [ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0 [ 2.901690] genpd_unlock_spin+0x20/0x30 [ 2.905724] genpd_add_device+0x100/0x2d0 [ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c [ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190 [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0 [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x
tach_by_id+0xc4/0x190 [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0 [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30 [ 2.929102] psci_dt_attach_cpu+0x24/0x90 [ 2.933230] psci_cpuidle_probe+0x2d4/0x46c [ 2.937534] platform_probe+0x68/0xe0 [ 2.941304] really_probe.part.0+0x9c/0x2fc [ 2.945605] __driver_probe_device+0x98/0x144 [ 2.950085] driver_probe_device+0x44/0x15c [ 2.954385] __device_attach_driver+0xb8/0x120 [ 2.958950] bus_for_each_drv+0x78/0xd0 [ 2.962896] __device_attach+0xd8/0x180 [ 2.966843] device_initial_probe+0x14/0x20 [ 2.971144] bus_probe_device+0x9c/0xa4 [ 2.975092] device_add+0x380/0x88c [ 2.978679] platform_device_add+0x114/0x234 [ 2.983067] platform_device_register_ful
[ 2.975092] device_add+0x380/0x88c [ 2.978679] platform_device_add+0x114/0x234 [ 2.983067] platform_device_register_full+0x100/0x190 [ 2.988344] psci_idle_init+0x6c/0xb0 [ 2.992113] do_one_initcall+0x74/0x3a0 [ 2.996060] kernel_init_freeable+0x2fc/0x384 [ 3.000543] kernel_init+0x28/0x130 [ 3.004132] ret_from_fork+0x10/0x20 [ 3.007817] irq event stamp: 319826 [ 3.011404] hardirqs last enabled at (319825): [<ffffd40e7eda0268>] __up_console_sem+0x78/0x84 [ 3.020332] hardirqs last disabled at (319826): [<ffffd40e7fd6d9d8>] el1_dbg+0x24/0x8c [ 3.028458] softirqs last enabled at (318312): [<ffffd40e7ec90410>] _stext+0x410/0x588 [ 3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>]
(318312): [<ffffd40e7ec90410>] _stext+0x410/0x588 [ 3.036678] softirqs last disabled at (318299): [<ffffd40e7ed1bf68>] __irq_exit_rcu+0x158/0x174 [ 3.045607] ---[ end trace 0000000000000000 ]--- References: - https://git.kernel.org/stable/c/3ec80d52b9b74b9e691997632a543c73eddfeba0 - https://git.kernel.org/stable/c/78c4d68b952f5f537788dbd454031ea9bf50f642 - https://git.kernel.org/stable/c/be8bc05f38d667eda1e820bc6f69234795be7809 - https://git.kernel.org/stable/c/0cccf9d4fb45f1acbc0bbf6d7e4d8d0fb7a10416 - https://git.kernel.org/stable/c/ede1ef1a7de973321699736ef96d01a4b9a6fe9e - https://git.kernel.org/stable/c/c29642ba72f87c0a3d7449f7db5d6d76a7ed53c3 - https://git.kernel.org/stable/c/2add538e