xamxte/cve-to-cwe huggingface dataset:
CVE-2020-36846: A buffer overflow, as described in CVE-2020-8927, exists in the embedded Brotli library.  Versions of IO::Compress::Brotli prior to 0.007 included a version of the brotli library prior to version 1.0.8, where an attacker controlling the input length of a "one-shot" decompression request to a script can trigger a crash, which happens when copying over chunks of data larger than 2 GiB. It is recommended to update your IO::Compress::Brotli module to 0.007 or later. If one cannot update, we recommend to use the "streaming" API as opposed to the "one-shot" API, and impose chunk size limits.
CVE-2025-20981: Improper access control in AudioService prior to SMR Jun-2025 Release 1 allows local attackers to access sensitive information.
CVE-2025-20986: Improper access control in ScreenCapture for Galaxy Watch prior to SMR Jun-2025 Release 1 allows local attackers to take screenshots.
CVE-2025-20987: Improper access control in fingerprint trustlet prior to SMR May-2025 Release 1 allows local privileged attackers to get a auth_token.
CVE-2025-20989: Improper logging in fingerprint trustlet prior to SMR May-2025 Release 1 allows local privileged attackers to get a hmac_key.
CVE-2025-20991: Improper export of Android application components in Bluetooth prior to SMR Jun-2025 Release 1 allows local attackers to make devices discoverable.
CVE-2025-20995: Improper handling of insufficient permission in ClientProvider in Samsung Internet installed on non-Samsung Device prior to version 28.0.0.59 allows local attackers to read and write arbitrary files.
CVE-2025-20996: Improper authorization in Smart Switch installed on non-Samsung Device prior to version 3.7.64.10 allows local attackers to read data with the privilege of Smart Switch. User interaction is required for triggering this vulnerability.
CVE-2025-38003: In the Linux kernel, the following vulnerability has been resolved:  can: bcm: add missing rcu read protection for procfs content  When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF).  As the removal of bcm_op's is already implemented with rcu handling this patch adds the missing rcu_read_lock() and makes sure the list entries are properly removed under rcu protection.
CVE-2025-3052: An arbitrary write vulnerability in Microsoft signed UEFI firmware allows for code execution of untrusted software. This allows an attacker to control its value, leading to arbitrary memory writes, including modification of critical firmware settings stored in NVRAM. Exploiting this vulnerability could enable security bypasses, persistence mechanisms, or full system compromise.
CVE-2025-4275: A vulnerability in the digital signature verification process does not properly validate variable attributes which allows an attacker to bypass signature verification by creating a non-authenticated NVRAM variable. An attacker may to execute arbitrary signed UEFI code and bypass Secure Boot.
CVE-2025-40914: Perl CryptX before version 0.087 contains a dependency that may be susceptible to an integer overflow.  CryptX embeds a version of the libtommath library that is susceptible to an integer overflow associated with CVE-2023-36328.
CVE-2025-4673: Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.
CVE-2025-38005: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: ti: k3-udma: Add missing locking  Recent kernels complain about a missing lock in k3-udma.c when the lock validator is enabled:  [    4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [    4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28 [    4.144867] Hardware name: pp-v12 (DT) [    4.148648] Workqueue: events udma_check_tx_completion [    4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [    4.160834] pc : udma_start.isra.0+0x34/0x238 [    4.165227] lr : udma_start.isra.0+0x30/0x238 [    4.169618] sp : ffffffc083cabcf0 [    4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [    4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [    4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [    4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [    4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [    4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [    4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [    4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [    4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [    4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [    4.244986] Call trace: [    4.247463]  udma_start.isra.0+0x34/0x238 [    4.251509]  udma_check_tx_completion+0xd0/0xdc [    4.256076]  process_one_work+0x244/0x3fc [    4.260129]  process_scheduled_works+0x6c/0x74 [    4.264610]  worker_thread+0x150/0x1dc [    4.268398]  kthread+0xd8/0xe8 [    4.271492]  ret_from_fork+0x10/0x20 [    4.275107] irq event stamp: 220 [    4.278363] hardirqs last  enabled at (219): [<ffffffc080a27c7c>] _raw_spin_unlock_irq+0x38/0x50 [    4.287183] hardirqs last disabled at (220): [<ffffffc080a1c154>] el1_dbg+0x24/0x50 [    4.294879] softirqs last  enabled at (182): [<ffffffc080037e68>] handle_softirqs+0x1c0/0x3cc [    4.303437] softirqs last disabled at (177): [<ffffffc080010170>] __do_softirq+0x1c/0x28 [    4.311559] ---[ end trace 0000000000000000 ]---  This commit adds the missing locking.
CVE-2025-38016: In the Linux kernel, the following vulnerability has been resolved:  HID: bpf: abort dispatch if device destroyed  The current HID bpf implementation assumes no output report/request will go through it after hid_bpf_destroy_device() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages.  The bug will be triggered if the conditions below are met:  A) a device under the driver has some LEDs on B) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver)  If condition A is met, hidinput_led_worker() is always scheduled *after* hid_bpf_destroy_device().  hid_destroy_device ` hid_bpf_destroy_device   ` cleanup_srcu_struct(&hdev->bpf.srcu) ` hid_remove_device   ` ...     ` led_classdev_unregister       ` led_trigger_set(led_cdev, NULL)         ` led_set_brightness(led_cdev, LED_OFF)           ` ...             ` input_inject_event               ` input_event_dispose                 ` hidinput_input_event                   ` schedule_work(&hid->led_work) [hidinput_led_worker]  This is fine when condition B is not met, where hidinput_led_worker() calls hid_ll_driver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request.  Otherwise, hidinput_led_worker() tries hid_hw_output_report() and leads to the bug.  hidinput_led_worker ` hid_hw_output_report   ` dispatch_hid_bpf_output_report     ` srcu_read_lock(&hdev->bpf.srcu)     ` srcu_read_unlock(&hdev->bpf.srcu, idx)  The bug has existed since the introduction [2] of dispatch_hid_bpf_output_report(). However, the same bug also exists in dispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinput_led_worker() falls back to hid_hw_raw_request() when hid_ll_driver->output_report() is uninplemented (e.g., logitech- djreceiver).  hidinput_led_worker ` hid_hw_output_report: -ENOSYS ` hid_hw_raw_request   ` dispatch_hid_bpf_raw_requests     ` srcu_read_lock(&hdev->bpf.srcu)     ` srcu_read_unlock(&hdev->bpf.srcu, idx)  Fix the issue by returning early in the two mentioned functions if hid_bpf has been marked as destroyed. Though dispatch_hid_bpf_device_event() handles input events, and there is no evidence that it may be called after the destruction, the same check, as a safety net, is also added to it to maintain the consistency among all dispatch functions.  The impact of the bug on other architectures is unclear. Even if it acts as a hidden failure, this is still dangerous because it corrupts whatever is on the address calculated by SRCU. Thus, CC'ing the stable list.  [1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets") [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for hid_hw_output_report")
CVE-2025-38017: In the Linux kernel, the following vulnerability has been resolved:  fs/eventpoll: fix endless busy loop after timeout has expired  After commit 0a65bc27bd64 ("eventpoll: Set epoll timeout if it's in the future"), the following program would immediately enter a busy loop in the kernel:  ``` int main() {   int e = epoll_create1(0);   struct epoll_event event = {.events = EPOLLIN};   epoll_ctl(e, EPOLL_CTL_ADD, 0, &event);   const struct timespec timeout = {.tv_nsec = 1};   epoll_pwait2(e, &event, 1, &timeout, 0); } ```  This happens because the given (non-zero) timeout of 1 nanosecond usually expires before ep_poll() is entered and then ep_schedule_timeout() returns false, but `timed_out` is never set because the code line that sets it is skipped.  This quickly turns into a soft lockup, RCU stalls and deadlocks, inflicting severe headaches to the whole system.  When the timeout has expired, we don't need to schedule a hrtimer, but we should set the `timed_out` variable.  Therefore, I suggest moving the ep_schedule_timeout() check into the `timed_out` expression instead of skipping it.  brauner: Note that there was an earlier fix by Joe Damato in response to my bug report in [1].
CVE-2025-38031: In the Linux kernel, the following vulnerability has been resolved:  padata: do not leak refcount in reorder_work  A recent patch that addressed a UAF introduced a reference count leak: the parallel_data refcount is incremented unconditionally, regardless of the return value of queue_work(). If the work item is already queued, the incremented refcount is never decremented.  Fix this by checking the return value of queue_work() and decrementing the refcount when necessary.  Resolves:  Unreferenced object 0xffff9d9f421e3d80 (size 192):   comm "cryptomgr_probe", pid 157, jiffies 4294694003   hex dump (first 32 bytes):     80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff  ...A............     d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00  ..............#.   backtrace (crc 838fb36):     __kmalloc_cache_noprof+0x284/0x320     padata_alloc_pd+0x20/0x1e0     padata_alloc_shell+0x3b/0xa0     0xffffffffc040a54d     cryptomgr_probe+0x43/0xc0     kthread+0xf6/0x1f0     ret_from_fork+0x2f/0x50     ret_from_fork_asm+0x1a/0x30
CVE-2025-38036: In the Linux kernel, the following vulnerability has been resolved:  drm/xe/vf: Perform early GT MMIO initialization to read GMDID  VFs need to communicate with the GuC to obtain the GMDID value and existing GuC functions used for that assume that the GT has it's MMIO members already setup. However, due to recent refactoring the gt->mmio is initialized later, and any attempt by the VF to use xe_mmio_read|write() from GuC functions will lead to NPD crash due to unset MMIO register address:  [] xe 0000:00:02.1: [drm] Running in SR-IOV VF mode [] xe 0000:00:02.1: [drm] GT0: sending H2G MMIO 0x5507 [] BUG: unable to handle page fault for address: 0000000000190240  Since we are already tweaking the id and type of the primary GT to mimic it's a Media GT before initializing the GuC communication, we can also call xe_gt_mmio_init() to perform early setup of the gt->mmio which will make those GuC functions work again.
CVE-2025-38037: In the Linux kernel, the following vulnerability has been resolved:  vxlan: Annotate FDB data races  The 'used' and 'updated' fields in the FDB entry structure can be accessed concurrently by multiple threads, leading to reports such as [1]. Can be reproduced using [2].  Suppress these reports by annotating these accesses using READ_ONCE() / WRITE_ONCE().  [1] BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmit  write to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0:  vxlan_xmit+0xb29/0x2380  dev_hard_start_xmit+0x84/0x2f0  __dev_queue_xmit+0x45a/0x1650  packet_xmit+0x100/0x150  packet_sendmsg+0x2114/0x2ac0  __sys_sendto+0x318/0x330  __x64_sys_sendto+0x76/0x90  x64_sys_call+0x14e8/0x1c00  do_syscall_64+0x9e/0x1a0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  read to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2:  vxlan_xmit+0xadf/0x2380  dev_hard_start_xmit+0x84/0x2f0  __dev_queue_xmit+0x45a/0x1650  packet_xmit+0x100/0x150  packet_sendmsg+0x2114/0x2ac0  __sys_sendto+0x318/0x330  __x64_sys_sendto+0x76/0x90  x64_sys_call+0x14e8/0x1c00  do_syscall_64+0x9e/0x1a0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  value changed: 0x00000000fffbac6e -> 0x00000000fffbac6f  Reported by Kernel Concurrency Sanitizer on: CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014  [2]  #!/bin/bash   set +H  echo whitelist > /sys/kernel/debug/kcsan  echo !vxlan_xmit > /sys/kernel/debug/kcsan   ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1  bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1  taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &  taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &
CVE-2025-38038: In the Linux kernel, the following vulnerability has been resolved:  cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost  set_boost is a per-policy function call, hence a driver wide lock is unnecessary. Also this mutex_acquire can collide with the mutex_acquire from the mode-switch path in status_store(), which can lead to a deadlock. So, remove it.
CVE-2025-38039: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled  When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns `-EINVAL` and triggers a `WARN_ON`, leading to an unnecessary call trace.  Update the code to handle this case more gracefully by returning `-EOPNOTSUPP` instead, while also providing a helpful user message.
CVE-2025-38061: In the Linux kernel, the following vulnerability has been resolved:  net: pktgen: fix access outside of user given buffer in pktgen_thread_write()  Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer).
CVE-2025-38062: In the Linux kernel, the following vulnerability has been resolved:  genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie  The IOMMU translation for MSI message addresses has been a 2-step process, separated in time:   1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address     is stored in the MSI descriptor when an MSI interrupt is allocated.   2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a     translated message address.  This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached.  Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up.  However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).  This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs.  Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor.  The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex.
CVE-2025-38074: In the Linux kernel, the following vulnerability has been resolved:  vhost-scsi: protect vq->log_used with vq->mutex  The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false.      vhost-thread                       QEMU-thread  vhost_scsi_complete_cmd_work() -> vhost_add_used()    -> vhost_add_used_n()       if (unlikely(vq->log_used))                                       QEMU disables vq->log_used                                       via VHOST_SET_VRING_ADDR.                                       mutex_lock(&vq->mutex);                                       vq->log_used = false now!                                       mutex_unlock(&vq->mutex);            QEMU gfree(vq->log_base)         log_used()         -> log_write(vq->log_base)  Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace.  The control queue path has the same issue.
CVE-2025-38080: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Increase block_sequence array size  [Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash.  [How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.
CVE-2022-49936: In the Linux kernel, the following vulnerability has been resolved:  USB: core: Prevent nested device-reset calls  Automatic kernel fuzzing revealed a recursive locking violation in usb-storage:  ============================================ WARNING: possible recursive locking detected 5.18.0 #3 Not tainted -------------------------------------------- kworker/1:3/1205 is trying to acquire lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230  but task is already holding lock: ffff888018638db8 (&us_interface_key[i]){+.+.}-{3:3}, at: usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230  ...  stack backtrace: CPU: 1 PID: 1205 Comm: kworker/1:3 Not tainted 5.18.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2988 [inline] check_deadlock kernel/locking/lockdep.c:3031 [inline] validate_chain kernel/locking/lockdep.c:3816 [inline] __lock_acquire.cold+0x152/0x3ca kernel/locking/lockdep.c:5053 lock_acquire kernel/locking/lockdep.c:5665 [inline] lock_acquire+0x1ab/0x520 kernel/locking/lockdep.c:5630 __mutex_lock_common kernel/locking/mutex.c:603 [inline] __mutex_lock+0x14f/0x1610 kernel/locking/mutex.c:747 usb_stor_pre_reset+0x35/0x40 drivers/usb/storage/usb.c:230 usb_reset_device+0x37d/0x9a0 drivers/usb/core/hub.c:6109 r871xu_dev_remove+0x21a/0x270 drivers/staging/rtl8712/usb_intf.c:622 usb_unbind_interface+0x1bd/0x890 drivers/usb/core/driver.c:458 device_remove drivers/base/dd.c:545 [inline] device_remove+0x11f/0x170 drivers/base/dd.c:537 __device_release_driver drivers/base/dd.c:1222 [inline] device_release_driver_internal+0x1a7/0x2f0 drivers/base/dd.c:1248 usb_driver_release_interface+0x102/0x180 drivers/usb/core/driver.c:627 usb_forced_unbind_intf+0x4d/0xa0 drivers/usb/core/driver.c:1118 usb_reset_device+0x39b/0x9a0 drivers/usb/core/hub.c:6114  This turned out not to be an error in usb-storage but rather a nested device reset attempt.  That is, as the rtl8712 driver was being unbound from a composite device in preparation for an unrelated USB reset (that driver does not have pre_reset or post_reset callbacks), its ->remove routine called usb_reset_device() -- thus nesting one reset call within another.  Performing a reset as part of disconnect processing is a questionable practice at best.  However, the bug report points out that the USB core does not have any protection against nested resets.  Adding a reset_in_progress flag and testing it will prevent such errors in the future.
CVE-2022-49958: In the Linux kernel, the following vulnerability has been resolved:  net/sched: fix netdevice reference leaks in attach_default_qdiscs()  In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails to attach qdisc because there is no memory in attach_one_default_qdisc(). Then dev->qdisc will be noop_qdisc by default. But the other queues may be able to successfully attach to default qdisc.  In this case, the fallback to noqueue process will be triggered. If the original attached qdisc is not released and a new one is directly attached, this will cause netdevice reference leaks.  The following is the bug log:  veth0: default qdisc (fq_codel) fail, fallback to noqueue unregister_netdevice: waiting for veth0 to become free. Usage count = 32 leaked reference.  qdisc_alloc+0x12e/0x210  qdisc_create_dflt+0x62/0x140  attach_one_default_qdisc.constprop.41+0x44/0x70  dev_activate+0x128/0x290  __dev_open+0x12a/0x190  __dev_change_flags+0x1a2/0x1f0  dev_change_flags+0x23/0x60  do_setlink+0x332/0x1150  __rtnl_newlink+0x52f/0x8e0  rtnl_newlink+0x43/0x70  rtnetlink_rcv_msg+0x140/0x3b0  netlink_rcv_skb+0x50/0x100  netlink_unicast+0x1bb/0x290  netlink_sendmsg+0x37c/0x4e0  sock_sendmsg+0x5f/0x70  ____sys_sendmsg+0x208/0x280  Fix this bug by clearing any non-noop qdiscs that may have been assigned before trying to re-attach.
CVE-2022-49964: In the Linux kernel, the following vulnerability has been resolved:  arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level  Though acpi_find_last_cache_level() always returned signed value and the document states it will return any errors caused by lack of a PPTT table, it never returned negative values before.  Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") however changed it by returning -ENOENT if no PPTT was found. The value returned from acpi_find_last_cache_level() is then assigned to unsigned fw_level.  It will result in the number of cache leaves calculated incorrectly as a huge value which will then cause the following warning from __alloc_pages as the order would be great than MAX_ORDER because of incorrect and huge cache leaves value.    |  WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314   |  Modules linked in:   |  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73   |  pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)   |  pc : __alloc_pages+0x74/0x314   |  lr : alloc_pages+0xe8/0x318   |  Call trace:   |   __alloc_pages+0x74/0x314   |   alloc_pages+0xe8/0x318   |   kmalloc_order_trace+0x68/0x1dc   |   __kmalloc+0x240/0x338   |   detect_cache_attributes+0xe0/0x56c   |   update_siblings_masks+0x38/0x284   |   store_cpu_topology+0x78/0x84   |   smp_prepare_cpus+0x48/0x134   |   kernel_init_freeable+0xc4/0x14c   |   kernel_init+0x2c/0x1b4   |   ret_from_fork+0x10/0x20  Fix the same by changing fw_level to be signed integer and return the error from init_cache_level() early in case of error.