xamxte/cve-to-cwe huggingface dataset:
CVE-2024-11053: When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances.  This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password.
CVE-2024-45337: Applications and libraries which misuse connection.serverAuthenticate (via callback field ServerConfig.PublicKeyCallback) may be susceptible to an authorization bypass. The documentation for ServerConfig.PublicKeyCallback says that "A call to this function does not guarantee that the key offered is in fact used to authenticate." Specifically, the SSH protocol allows clients to inquire about whether a public key is acceptable before proving control of the corresponding private key. PublicKeyCallback may be called with multiple keys, and the order in which the keys were provided cannot be used to infer which key the client successfully authenticated with, if any. Some applications, which store the key(s) passed to PublicKeyCallback (or derived information) and make security relevant determinations based on it once the connection is established, may make incorrect assumptions. For example, an attacker may send public keys A and B, and then authenticate with A. PublicKeyCallback would be called only twice, first with A and then with B. A vulnerable application may then make authorization decisions based on key B for which the attacker does not actually control the private key. Since this API is widely misused, as a partial mitigation golang.org/x/cry...@v0.31.0 enforces the property that, when successfully authenticating via public key, the last key passed to ServerConfig.PublicKeyCallback will be the key used to authenticate the connection. PublicKeyCallback will now be called multiple times with the same key, if necessary. Note that the client may still not control the last key passed to PublicKeyCallback if the connection is then authenticated with a different method, such as PasswordCallback, KeyboardInteractiveCallback, or NoClientAuth. Users should be using the Extensions field of the Permissions return value from the various authentication callbacks to record data associated with the authentication attempt instead of referencing external state. Once the connection is established the state corresponding to the successful authentication attempt can be retrieved via the ServerConn.Permissions field. Note that some third-party libraries misuse the Permissions type by sharing it across authentication attempts; users of third-party libraries should refer to the relevant projects for guidance.
CVE-2024-44290: This issue was addressed with improved redaction of sensitive information. This issue is fixed in iOS 18.1 and iPadOS 18.1, watchOS 11.1. An app may be able to determine a user’s current location.
CVE-2024-54486: The issue was addressed with improved checks. This issue is fixed in iPadOS 17.7.3, watchOS 11.2, visionOS 2.2, tvOS 18.2, macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. Processing a maliciously crafted font may result in the disclosure of process memory.
CVE-2024-54492: This issue was addressed by using HTTPS when sending information over the network. This issue is fixed in macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, iPadOS 17.7.3, visionOS 2.2. An attacker in a privileged network position may be able to alter network traffic.
CVE-2024-54498: A path handling issue was addressed with improved validation. This issue is fixed in macOS Sequoia 15.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An app may be able to break out of its sandbox.
CVE-2024-54500: The issue was addressed with improved checks. This issue is fixed in iPadOS 17.7.3, watchOS 11.2, visionOS 2.2, tvOS 18.2, macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. Processing a maliciously crafted image may result in disclosure of process memory.
CVE-2024-55969: DocIO in Syncfusion Essential Studio for ASP.NET MVC before 27.1.55 throws XMLException during the resaving of a DOCX document with an external reference XML, aka I640714.
CVE-2024-5333: The Events Calendar WordPress plugin before 6.8.2.1 is missing access checks in the REST API, allowing for unauthenticated users to access information about password protected events.
CVE-2024-9679: A Hardcoded Cryptographic key vulnerability existed in DLP Extension 11.11.1.3 which allowed the decryption of previously encrypted user credentials.
CVE-2024-2201: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.
CVE-2024-53240: In the Linux kernel, the following vulnerability has been resolved:  xen/netfront: fix crash when removing device  When removing a netfront device directly after a suspend/resume cycle it might happen that the queues have not been setup again, causing a crash during the attempt to stop the queues another time.  Fix that by checking the queues are existing before trying to stop them.  This is XSA-465 / CVE-2024-53240.
CVE-2024-53158: In the Linux kernel, the following vulnerability has been resolved:  soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()  This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration.  However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clk_perf_tbl[] array.
CVE-2024-53176: In the Linux kernel, the following vulnerability has been resolved:  smb: During unmount, ensure all cached dir instances drop their dentry  The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:  BUG: Dentry ffff88814f37e358{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!  This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:  - Receiving a lease break from the server - Server reconnection triggers invalidate_all_cached_dirs(), which   removes all the cfids from the list - The laundromat thread decides to expire an old cfid.  To solve these problems, dropping the dentry is done in queued work done in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.  The final cleanup work for cleaning up a cfid is performed via work queued in the serverclose_wq workqueue; this is done separate from dropping the dentries so that close_all_cached_dirs() doesn't block on any server operations.  Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.  While we're here, add proper locking to close_all_cached_dirs(), and locking around the freeing of cfid->dentry.
CVE-2024-53190: In the Linux kernel, the following vulnerability has been resolved:  wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures  Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path:  (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure.  (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total).  This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example:  task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace:  __schedule+0xe22/0xeb6  schedule_timeout+0xe7/0x132  __wait_for_common+0xb5/0x12e  usb_start_wait_urb+0xc5/0x1ef  ? usb_alloc_urb+0x95/0xa4  usb_control_msg+0xff/0x184  _usbctrl_vendorreq_sync+0xa0/0x161  _usb_read_sync+0xb3/0xc5  read_efuse_byte+0x13c/0x146  read_efuse+0x351/0x5f0  efuse_read_all_map+0x42/0x52  rtl_efuse_shadow_map_update+0x60/0xef  rtl_get_hwinfo+0x5d/0x1c2  rtl92cu_read_eeprom_info+0x10a/0x8d5  ? rtl92c_read_chip_version+0x14f/0x17e  rtl_usb_probe+0x323/0x851  usb_probe_interface+0x278/0x34b  really_probe+0x202/0x4a4  __driver_probe_device+0x166/0x1b2  driver_probe_device+0x2f/0xd8  [...]  We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense.  [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")  [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.
CVE-2024-53202: In the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Fix possible resource leak in fw_log_firmware_info()  The alg instance should be released under the exception path, otherwise there may be resource leak here.  To mitigate this, free the alg instance with crypto_free_shash when kmalloc fails.
CVE-2024-56539: In the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()  Replace one-element array with a flexible-array member in `struct mwifiex_ie_types_wildcard_ssid_params` to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana):  [  356.775250] ------------[ cut here ]------------ [  356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]  The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:      ssid_len = user_scan_in->ssid_list[i].ssid_len;     [...]     memcpy(wildcard_ssid_tlv->ssid,            user_scan_in->ssid_list[i].ssid, ssid_len);  There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.
CVE-2024-56543: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath12k: Skip Rx TID cleanup for self peer  During peer create, dp setup for the peer is done where Rx TID is updated for all the TIDs. Peer object for self peer will not go through dp setup.  When core halts, dp cleanup is done for all the peers. While cleanup, rx_tid::ab is accessed which causes below stack trace for self peer.  WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851 Call Trace: __warn+0x7b/0x1a0 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] report_bug+0x10b/0x200 handle_bug+0x3f/0x70 exc_invalid_op+0x13/0x60 asm_exc_invalid_op+0x16/0x20 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k] ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k] ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k] ath12k_core_halt+0x3b/0x100 [ath12k] ath12k_core_reset+0x494/0x4c0 [ath12k]  sta object in peer will be updated when remote peer is created. Hence use peer::sta to detect the self peer and skip the cleanup.  Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
CVE-2024-56550: In the Linux kernel, the following vulnerability has been resolved:  s390/stacktrace: Use break instead of return statement  arch_stack_walk_user_common() contains a return statement instead of a break statement in case store_ip() fails while trying to store a callchain entry of a user space process. This may lead to a missing pagefault_enable() call.  If this happens any subsequent page fault of the process won't be resolved by the page fault handler and this in turn will lead to the process being killed.  Use a break instead of a return statement to fix this.
CVE-2024-56562: In the Linux kernel, the following vulnerability has been resolved:  i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()  if (dev->boardinfo && dev->boardinfo->init_dyn_addr)                                       ^^^ here check "init_dyn_addr"  i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...)                    ^^^^        free "dyn_addr" Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".
CVE-2024-56563: In the Linux kernel, the following vulnerability has been resolved:  ceph: fix cred leak in ceph_mds_check_access()  get_current_cred() increments the reference counter, but the put_cred() call was missing.
CVE-2024-56564: In the Linux kernel, the following vulnerability has been resolved:  ceph: pass cred pointer to ceph_mds_auth_match()  This eliminates a redundant get_current_cred() call, because ceph_mds_check_access() has already obtained this pointer.  As a side effect, this also fixes a reference leak in ceph_mds_auth_match(): by omitting the get_current_cred() call, no additional cred reference is taken.
CVE-2024-56583: In the Linux kernel, the following vulnerability has been resolved:  sched/deadline: Fix warning in migrate_enable for boosted tasks  When running the following command:  while true; do     stress-ng --cyclic 30 --timeout 30s --minimize --quiet done  a warning is eventually triggered:  WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Call Trace:  <TASK>  ? show_trace_log_lvl+0x1c4/0x2df  ? enqueue_dl_entity+0x631/0x6e0  ? setup_new_dl_entity+0x13e/0x180  ? __warn+0x7e/0xd0  ? report_bug+0x11a/0x1a0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  enqueue_dl_entity+0x631/0x6e0  enqueue_task_dl+0x7d/0x120  __do_set_cpus_allowed+0xe3/0x280  __set_cpus_allowed_ptr_locked+0x140/0x1d0  __set_cpus_allowed_ptr+0x54/0xa0  migrate_enable+0x7e/0x150  rt_spin_unlock+0x1c/0x90  group_send_sig_info+0xf7/0x1a0  ? kill_pid_info+0x1f/0x1d0  kill_pid_info+0x78/0x1d0  kill_proc_info+0x5b/0x110  __x64_sys_kill+0x93/0xc0  do_syscall_64+0x5c/0xf0  entry_SYSCALL_64_after_hwframe+0x6e/0x76  RIP: 0033:0x7f0dab31f92b  This warning occurs because set_cpus_allowed dequeues and enqueues tasks with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary, hence the WARN_ON call.  Check if we are requeueing a boosted task and avoid calling setup_new_dl_entity if that's the case.
CVE-2024-56589: In the Linux kernel, the following vulnerability has been resolved:  scsi: hisi_sas: Add cond_resched() for no forced preemption model  For no forced preemption model kernel, in the scenario where the expander is connected to 12 high performance SAS SSDs, the following call trace may occur:  [  214.409199][  C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211] [  214.568533][  C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [  214.575224][  C240] pc : fput_many+0x8c/0xdc [  214.579480][  C240] lr : fput+0x1c/0xf0 [  214.583302][  C240] sp : ffff80002de2b900 [  214.587298][  C240] x29: ffff80002de2b900 x28: ffff1082aa412000 [  214.593291][  C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000 [  214.599284][  C240] x25: ffff1062bbac5c40 x24: 0000000000001000 [  214.605277][  C240] x23: 000000000000000a x22: 0000000000000001 [  214.611270][  C240] x21: 0000000000001000 x20: 0000000000000000 [  214.617262][  C240] x19: ffff3062a41ae580 x18: 0000000000010000 [  214.623255][  C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0 [  214.629248][  C240] x15: ffffffffffffffff x14: 0000000003ffffff [  214.635241][  C240] x13: 000000000000ffff x12: 000000000000029c [  214.641234][  C240] x11: 0000000000000006 x10: ffff80003a9f7fd0 [  214.647226][  C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001 [  214.653219][  C240] x7 : 0000000000000002 x6 : 0000000000000080 [  214.659212][  C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554 [  214.665205][  C240] x3 : 0000000000000002 x2 : 0000000000000020 [  214.671198][  C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8 [  214.677191][  C240] Call trace: [  214.680320][  C240]  fput_many+0x8c/0xdc [  214.684230][  C240]  fput+0x1c/0xf0 [  214.687707][  C240]  aio_complete_rw+0xd8/0x1fc [  214.692225][  C240]  blkdev_bio_end_io+0x98/0x140 [  214.696917][  C240]  bio_endio+0x160/0x1bc [  214.701001][  C240]  blk_update_request+0x1c8/0x3bc [  214.705867][  C240]  scsi_end_request+0x3c/0x1f0 [  214.710471][  C240]  scsi_io_completion+0x7c/0x1a0 [  214.715249][  C240]  scsi_finish_command+0x104/0x140 [  214.720200][  C240]  scsi_softirq_done+0x90/0x180 [  214.724892][  C240]  blk_mq_complete_request+0x5c/0x70 [  214.730016][  C240]  scsi_mq_done+0x48/0xac [  214.734194][  C240]  sas_scsi_task_done+0xbc/0x16c [libsas] [  214.739758][  C240]  slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw] [  214.746185][  C240]  cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw] [  214.752179][  C240]  irq_thread_fn+0x34/0xa4 [  214.756435][  C240]  irq_thread+0xc4/0x130 [  214.760520][  C240]  kthread+0x108/0x13c [  214.764430][  C240]  ret_from_fork+0x10/0x18  This is because in the hisi_sas driver, both the hardware interrupt handler and the interrupt thread are executed on the same CPU. In the performance test scenario, function irq_wait_for_interrupt() will always return 0 if lots of interrupts occurs and the CPU will be continuously consumed. As a result, the CPU cannot run the watchdog thread. When the watchdog time exceeds the specified time, call trace occurs.  To fix it, add cond_resched() to execute the watchdog thread.
CVE-2024-56638: In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_inner: incorrect percpu area handling under softirq  Softirq can interrupt ongoing packet from process context that is walking over the percpu area that contains inner header offsets.  Disable bh and perform three checks before restoring the percpu inner header offsets to validate that the percpu area is valid for this skbuff:  1) If the NFT_PKTINFO_INNER_FULL flag is set on, then this skbuff    has already been parsed before for inner header fetching to    register.  2) Validate that the percpu area refers to this skbuff using the    skbuff pointer as a cookie. If there is a cookie mismatch, then    this skbuff needs to be parsed again.  3) Finally, validate if the percpu area refers to this tunnel type.  Only after these three checks the percpu area is restored to a on-stack copy and bh is enabled again.  After inner header fetching, the on-stack copy is stored back to the percpu area.
CVE-2024-56639: In the Linux kernel, the following vulnerability has been resolved:  net: hsr: must allocate more bytes for RedBox support  Blamed commit forgot to change hsr_init_skb() to allocate larger skb for RedBox case.  Indeed, send_hsr_supervision_frame() will add two additional components (struct hsr_sup_tlv and struct hsr_sup_payload)  syzbot reported the following crash: skbuff: skb_over_panic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0 ------------[ cut here ]------------  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 UID: 0 PID: 7611 Comm: syz-executor Not tainted 6.12.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014  RIP: 0010:skb_panic+0x157/0x1d0 net/core/skbuff.c:206 Code: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282 RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69 RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005 RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a R13: 0000000000000006 R14: ffff88804b938130 R15: 0000000000000140 FS:  000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <IRQ>   skb_over_panic net/core/skbuff.c:211 [inline]   skb_put+0x174/0x1b0 net/core/skbuff.c:2617   send_hsr_supervision_frame+0x6fa/0x9e0 net/hsr/hsr_device.c:342   hsr_proxy_announce+0x1a3/0x4a0 net/hsr/hsr_device.c:436   call_timer_fn+0x1a0/0x610 kernel/time/timer.c:1794   expire_timers kernel/time/timer.c:1845 [inline]   __run_timers+0x6e8/0x930 kernel/time/timer.c:2419   __run_timer_base kernel/time/timer.c:2430 [inline]   __run_timer_base kernel/time/timer.c:2423 [inline]   run_timer_base+0x111/0x190 kernel/time/timer.c:2439   run_timer_softirq+0x1a/0x40 kernel/time/timer.c:2449   handle_softirqs+0x213/0x8f0 kernel/softirq.c:554   __do_softirq kernel/softirq.c:588 [inline]   invoke_softirq kernel/softirq.c:428 [inline]   __irq_exit_rcu kernel/softirq.c:637 [inline]   irq_exit_rcu+0xbb/0x120 kernel/softirq.c:649   instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]   sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049  </IRQ>