xamxte/cve-to-cwe huggingface dataset:
CVE-2024-12366: PandasAI uses an interactive prompt function that is vulnerable to prompt injection and run arbitrary Python code that can lead to Remote Code Execution (RCE) instead of the intended explanation of the natural language processing by the LLM.
CVE-2021-47649: In the Linux kernel, the following vulnerability has been resolved:  udmabuf: validate ubuf->pagecount  Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR.  ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR.  Fix it by validating ubuf->pagecount before passing it to kmalloc_array().
CVE-2021-47659: In the Linux kernel, the following vulnerability has been resolved:  drm/plane: Move range check for format_count earlier  While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.
CVE-2022-49048: In the Linux kernel, the following vulnerability has been resolved:  ipv6: fix panic when forwarding a pkt with no in6 dev  kongweibin reported a kernel panic in ip6_forward() when input interface has no in6 dev associated.  The following tc commands were used to reproduce this panic: tc qdisc del dev vxlan100 root tc qdisc add dev vxlan100 root netem corrupt 5%
CVE-2022-49052: In the Linux kernel, the following vulnerability has been resolved:  mm: fix unexpected zeroed page mapping with zram swap  Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly.        CPU A                        CPU B    do_swap_page                do_swap_page   SWP_SYNCHRONOUS_IO path     SWP_SYNCHRONOUS_IO path   swap_readpage valid data     swap_slot_free_notify       delete zram entry                               swap_readpage zeroed(invalid) data                               pte_lock                               map the *zero data* to userspace                               pte_unlock   pte_lock   if (!pte_same)     goto out_nomap;   pte_unlock   return and next refault will   read zeroed data  The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device.  In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock.  Thus, this patch gets rid of the swap_slot_free_notify function.  With this patch, CPU A will see correct data.        CPU A                        CPU B    do_swap_page                do_swap_page   SWP_SYNCHRONOUS_IO path     SWP_SYNCHRONOUS_IO path                               swap_readpage original data                               pte_lock                               map the original data                               swap_free                                 swap_range_free                                   bd_disk->fops->swap_slot_free_notify   swap_readpage read zeroed data                               pte_unlock   pte_lock   if (!pte_same)     goto out_nomap;   pte_unlock   return   on next refault will see mapped data by CPU B  The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space.  However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly.
CVE-2022-49088: In the Linux kernel, the following vulnerability has been resolved:  dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe  This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak.
CVE-2022-49103: In the Linux kernel, the following vulnerability has been resolved:  NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify()  [You don't often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]  The reference counting issue happens in two error paths in the function _nfs42_proc_copy_notify(). In both error paths, the function simply returns the error code and forgets to balance the refcount of object `ctx`, bumped by get_nfs_open_context() earlier, which may cause refcount leaks.  Fix it by balancing refcount of the `ctx` object before the function returns in both error paths.
CVE-2022-49109: In the Linux kernel, the following vulnerability has been resolved:  ceph: fix inode reference leakage in ceph_get_snapdir()  The ceph_get_inode() will search for or insert a new inode into the hash for the given vino, and return a reference to it. If new is non-NULL, its reference is consumed.  We should release the reference when in error handing cases.
CVE-2022-49112: In the Linux kernel, the following vulnerability has been resolved:  mt76: fix monitor mode crash with sdio driver  mt7921s driver may receive frames with fragment buffers. If there is a CTS packet received in monitor mode, the payload is 10 bytes only and need 6 bytes header padding after RXD buffer. However, only RXD in the first linear buffer, if we pull buffer size RXD-size+6 bytes with skb_pull(), that would trigger "BUG_ON(skb->len < skb->data_len)" in __skb_pull().  To avoid the nonlinear buffer issue, enlarge the RXD size from 128 to 256 to make sure all MCU operation in linear buffer.  [   52.007562] kernel BUG at include/linux/skbuff.h:2313! [   52.007578] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [   52.007987] pc : skb_pull+0x48/0x4c [   52.008015] lr : mt7921_queue_rx_skb+0x494/0x890 [mt7921_common] [   52.008361] Call trace: [   52.008377]  skb_pull+0x48/0x4c [   52.008400]  mt76s_net_worker+0x134/0x1b0 [mt76_sdio 35339a92c6eb7d4bbcc806a1d22f56365565135c] [   52.008431]  __mt76_worker_fn+0xe8/0x170 [mt76 ef716597d11a77150bc07e3fdd68eeb0f9b56917] [   52.008449]  kthread+0x148/0x3ac [   52.008466]  ret_from_fork+0x10/0x30
CVE-2022-49113: In the Linux kernel, the following vulnerability has been resolved:  powerpc/secvar: fix refcount leak in format_show()  Refcount leak will happen when format_show returns failure in multiple cases. Unified management of of_node_put can fix this problem.
CVE-2022-49117: In the Linux kernel, the following vulnerability has been resolved:  mips: ralink: fix a refcount leak in ill_acc_of_setup()  of_node_put(np) needs to be called when pdev == NULL.
CVE-2022-49128: In the Linux kernel, the following vulnerability has been resolved:  drm/bridge: Add missing pm_runtime_put_sync  pm_runtime_get_sync() will increase the rumtime PM counter even when it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Besides, a matching decrement is needed on the error handling path to keep the counter balanced.
CVE-2022-49131: In the Linux kernel, the following vulnerability has been resolved:  ath11k: fix kernel panic during unload/load ath11k modules  Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix the following kernel panic when unload/load ath11k modules for few iterations.  [  971.201365] Unable to handle kernel paging request at virtual address 6d97a208 [  971.204227] pgd = 594c2919 [  971.211478] [6d97a208] *pgd=00000000 [  971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [  971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0 [  971.434256] Hardware name: Generic DT based system [  971.440165] PC is at napi_by_id+0x10/0x40 [  971.445019] LR is at netif_napi_add+0x160/0x1dc  [  971.743127] (napi_by_id) from [<807d89a0>] (netif_napi_add+0x160/0x1dc) [  971.751295] (netif_napi_add) from [<7f1209ac>] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb]) [  971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [<7f12135c>] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb]) [  971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [<80666864>] (platform_drv_probe+0x48/0x94) [  971.779670] (platform_drv_probe) from [<80664718>] (really_probe+0x1c8/0x450) [  971.789389] (really_probe) from [<80664cc4>] (driver_probe_device+0x15c/0x1b8) [  971.797547] (driver_probe_device) from [<80664f60>] (device_driver_attach+0x44/0x60) [  971.805795] (device_driver_attach) from [<806650a0>] (__driver_attach+0x124/0x140) [  971.814822] (__driver_attach) from [<80662adc>] (bus_for_each_dev+0x58/0xa4) [  971.823328] (bus_for_each_dev) from [<80663a2c>] (bus_add_driver+0xf0/0x1e8) [  971.831662] (bus_add_driver) from [<806658a4>] (driver_register+0xa8/0xf0) [  971.839822] (driver_register) from [<8030269c>] (do_one_initcall+0x78/0x1ac) [  971.847638] (do_one_initcall) from [<80392524>] (do_init_module+0x54/0x200) [  971.855968] (do_init_module) from [<803945b0>] (load_module+0x1e30/0x1ffc) [  971.864126] (load_module) from [<803948b0>] (sys_init_module+0x134/0x17c) [  971.871852] (sys_init_module) from [<80301000>] (ret_fast_syscall+0x0/0x50)  Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1
CVE-2022-49133: In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: svm range restore work deadlock when process exit  kfd_process_notifier_release flush svm_range_restore_work which calls svm_range_list_lock_and_flush_work to flush deferred_list work, but if deferred_list work mmput release the last user, it will call exit_mmap -> notifier_release, it is deadlock with below backtrace.  Move flush svm_range_restore_work to kfd_process_wq_release to avoid deadlock. Then svm_range_restore_work take task->mm ref to avoid mm is gone while validating and mapping ranges to GPU.  Workqueue: events svm_range_deferred_list_work [amdgpu] Call Trace:  wait_for_completion+0x94/0x100  __flush_work+0x12a/0x1e0  __cancel_work_timer+0x10e/0x190  cancel_delayed_work_sync+0x13/0x20  kfd_process_notifier_release+0x98/0x2a0 [amdgpu]  __mmu_notifier_release+0x74/0x1f0  exit_mmap+0x170/0x200  mmput+0x5d/0x130  svm_range_deferred_list_work+0x104/0x230 [amdgpu]  process_one_work+0x220/0x3c0
CVE-2022-49137: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj  This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks.  Fix it by decreasing the refcount of specific object before returning the error code.
CVE-2022-49147: In the Linux kernel, the following vulnerability has been resolved:  block: Fix the maximum minor value is blk_alloc_ext_minor()  ida_alloc_range(..., min, max, ...) returns values from min to max, inclusive.  So, NR_EXT_DEVT is a valid idx returned by blk_alloc_ext_minor().  This is an issue because in device_add_disk(), this value is used in:    ddev->devt = MKDEV(disk->major, disk->first_minor); and NR_EXT_DEVT is '(1 << MINORBITS)'.  So, should 'disk->first_minor' be NR_EXT_DEVT, it would overflow.
CVE-2022-49150: In the Linux kernel, the following vulnerability has been resolved:  rtc: gamecube: Fix refcount leak in gamecube_rtc_read_offset_from_sram  The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount.
CVE-2022-49151: In the Linux kernel, the following vulnerability has been resolved:  can: mcba_usb: properly check endpoint type  Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. We should check that in endpoint is actually present to prevent this warning.  Found pipes are now saved to struct mcba_priv and code uses them directly instead of making pipes in place.  Fail log:  | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Modules linked in: | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42147f #0 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Workqueue: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Call Trace: |  <TASK> |  mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline] |  mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 |  usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 |  call_driver_probe drivers/base/dd.c:517 [inline]
CVE-2022-49156: In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Fix scheduling while atomic  The driver makes a call into midlayer (fc_remote_port_delete) which can put the thread to sleep. The thread that originates the call is in interrupt context. The combination of the two trigger a crash. Schedule the call in non-interrupt context where it is more safe.  kernel: BUG: scheduling while atomic: swapper/7/0/0x00010000 kernel: Call Trace: kernel:  <IRQ> kernel:  dump_stack+0x66/0x81 kernel:  __schedule_bug.cold.90+0x5/0x1d kernel:  __schedule+0x7af/0x960 kernel:  schedule+0x28/0x80 kernel:  schedule_timeout+0x26d/0x3b0 kernel:  wait_for_completion+0xb4/0x140 kernel:  ? wake_up_q+0x70/0x70 kernel:  __wait_rcu_gp+0x12c/0x160 kernel:  ? sdev_evt_alloc+0xc0/0x180 [scsi_mod] kernel:  synchronize_sched+0x6c/0x80 kernel:  ? call_rcu_bh+0x20/0x20 kernel:  ? __bpf_trace_rcu_invoke_callback+0x10/0x10 kernel:  sdev_evt_alloc+0xfd/0x180 [scsi_mod] kernel:  starget_for_each_device+0x85/0xb0 [scsi_mod] kernel:  ? scsi_init_io+0x360/0x3d0 [scsi_mod] kernel:  scsi_init_io+0x388/0x3d0 [scsi_mod] kernel:  device_for_each_child+0x54/0x90 kernel:  fc_remote_port_delete+0x70/0xe0 [scsi_transport_fc] kernel:  qla2x00_schedule_rport_del+0x62/0xf0 [qla2xxx] kernel:  qla2x00_mark_device_lost+0x9c/0xd0 [qla2xxx] kernel:  qla24xx_handle_plogi_done_event+0x55f/0x570 [qla2xxx] kernel:  qla2x00_async_login_sp_done+0xd2/0x100 [qla2xxx] kernel:  qla24xx_logio_entry+0x13a/0x3c0 [qla2xxx] kernel:  qla24xx_process_response_queue+0x306/0x400 [qla2xxx] kernel:  qla24xx_msix_rsp_q+0x3f/0xb0 [qla2xxx] kernel:  __handle_irq_event_percpu+0x40/0x180 kernel:  handle_irq_event_percpu+0x30/0x80 kernel:  handle_irq_event+0x36/0x60
CVE-2022-49161: In the Linux kernel, the following vulnerability has been resolved:  ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probe  The device_node pointer is returned by of_parse_phandle()  with refcount incremented. We should use of_node_put() on it when done.  This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. Fix this by calling of_node_put() in error handling too.
CVE-2022-49167: 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 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().
CVE-2022-49169: 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/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: 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: [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]  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
CVE-2022-49173: 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.
CVE-2022-49174: 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_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 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 [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 [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
CVE-2022-49183: In the Linux kernel, the following vulnerability has been resolved:  net/sched: act_ct: fix ref leak when switching zones  When switching zones or network namespaces without doing a ct clear in between, it is now leaking a reference to the old ct entry. That's because tcf_ct_skb_nfct_cached() returns false and tcf_ct_flow_table_lookup() may simply overwrite it.  The fix is to, as the ct entry is not reusable, free it already at tcf_ct_skb_nfct_cached().
CVE-2022-49185: In the Linux kernel, the following vulnerability has been resolved:  pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe  This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
CVE-2022-49193: In the Linux kernel, the following vulnerability has been resolved:  ice: fix 'scheduling while atomic' on aux critical err interrupt  There's a kernel BUG splat on processing aux critical error interrupts in ice_misc_intr():  [ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Call Trace: [ 2101.063229]  <IRQ> [ 2101.065252]  dump_stack+0x41/0x60 [ 2101.068587]  __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060]  __schedule+0x6a4/0x830 [ 2101.076570]  schedule+0x35/0xa0 [ 2101.079727]  schedule_preempt_disabled+0xa/0x10 [ 2101.084284]  __mutex_lock.isra.7+0x310/0x420 [ 2101.088580]  ? ice_misc_intr+0x201/0x2e0 [ice] [ 2101.093078]  ice_send_event_to_aux+0x25/0x70 [ice] [ 2101.097921]  ice_misc_intr+0x220/0x2e0 [ice] [ 2101.102232]  __handle_irq_event_percpu+0x40/0x180 [ 2101.106965]  handle_irq_event_percpu+0x30/0x80 [ 2101.111434]  handle_irq_event+0x36/0x53 [ 2101.115292]  handle_edge_irq+0x82/0x190 [ 2101.119148]  handle_irq+0x1c/0x30 [ 2101.122480]  do_IRQ+0x49/0xd0 [ 2101.125465]  common_interrupt+0xf/0xf [ 2101.129146]  </IRQ> ...  As Andrew correctly mentioned previously[0], the following call ladder happens:  ice_misc_intr() <- hardirq   ice_send_event_to_aux()     device_lock()       mutex_lock()         might_sleep()           might_resched() <- oops  Add a new PF state bit which indicates that an aux critical error occurred and serve it in ice_service_task() in process context. The new ice_pf::oicr_err_reg is read-write in both hardirq and process contexts, but only 3 bits of non-critical data probably aren't worth explicit synchronizing (and they're even in the same byte [31:24]).  [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch