{"vulnerability": "CVE-2024-4771", "sightings": [{"uuid": "97f631ec-8b00-40f5-b83d-54f8a81b7f15", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47717", "type": "seen", "source": "https://t.me/cvedetector/8456", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47717 - RISC-V KVM PMU Snapshot NULL Pointer Crash\", \n  \"Content\": \"CVE ID : CVE-2024-47717 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nRISC-V: KVM: Don't zero-out PMU snapshot area before freeing data  \n  \nWith the latest Linux-6.11-rc3, the below NULL pointer crash is observed  \nwhen SBI PMU snapshot is enabled for the guest and the guest is forcefully  \npowered-off.  \n  \n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508  \n  Oops [#1]  \n  Modules linked in: kvm  \n  CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3  \n  Hardware name: riscv-virtio,qemu (DT)  \n  epc : __kvm_write_guest_page+0x94/0xa6 [kvm]  \n   ra : __kvm_write_guest_page+0x54/0xa6 [kvm]  \n  epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0  \n   gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000  \n   t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0  \n   s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086  \n   a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0  \n   a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc  \n   s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000  \n   s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000  \n   s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001  \n   s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3  \n   t5 : ffffffff814126e0 t6 : ffffffff81412700  \n  status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d  \n  [] __kvm_write_guest_page+0x94/0xa6 [kvm]  \n  [] kvm_vcpu_write_guest+0x56/0x90 [kvm]  \n  [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm]  \n  [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm]  \n  [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm]  \n  [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm]  \n  [] kvm_destroy_vcpus+0x5a/0xda [kvm]  \n  [] kvm_arch_destroy_vm+0x14/0x28 [kvm]  \n  [] kvm_destroy_vm+0x168/0x2a0 [kvm]  \n  [] kvm_put_kvm+0x3c/0x58 [kvm]  \n  [] kvm_vm_release+0x22/0x2e [kvm]  \n  \nClearly, the kvm_vcpu_write_guest() function is crashing because it is  \nbeing called from kvm_pmu_clear_snapshot_area() upon guest tear down.  \n  \nTo address the above issue, simplify the kvm_pmu_clear_snapshot_area() to  \nnot zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because  \nthe guest is anyway being tore down.  \n  \nThe kvm_pmu_clear_snapshot_area() is also called when guest changes  \nPMU snapshot area of a VCPU but even in this case the previous PMU  \nsnaphsot area must not be zeroed-out because the guest might have  \nreclaimed the pervious PMU snapshot area for some other purpose. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T15:09:37.000000Z"}, {"uuid": "68b2aae6-32ef-4faf-89f0-31a68ce6dcc4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47715", "type": "seen", "source": "https://t.me/cvedetector/8477", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47715 - ZyXEL EX5700 WiFi mt76 Kernel Oops Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-47715 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nwifi: mt76: mt7915: fix oops on non-dbdc mt7986  \n  \nmt7915_band_config() sets band_idx = 1 on the main phy for mt7986  \nwith MT7975_ONE_ADIE or MT7976_ONE_ADIE.  \n  \nCommit 0335c034e726 (\"wifi: mt76: fix race condition related to  \nchecking tx queue fill status\") introduced a dereference of the  \nphys array indirectly indexed by band_idx via wcid->phy_idx in  \nmt76_wcid_cleanup(). This caused the following Oops on affected  \nmt7986 devices:  \n  \n Unable to handle kernel read from unreadable memory at virtual address 0000000000000024  \n Mem abort info:  \n   ESR = 0x0000000096000005  \n   EC = 0x25: DABT (current EL), IL = 32 bits  \n   SET = 0, FnV = 0  \n   EA = 0, S1PTW = 0  \n   FSC = 0x05: level 1 translation fault  \n Data abort info:  \n   ISV = 0, ISS = 0x00000005  \n   CM = 0, WnR = 0  \n user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000  \n [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000  \n Internal error: Oops: 0000000096000005 [#1] SMP  \n Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ...  \n CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0  \n Hardware name: ZyXEL EX5700 (Telenor) (DT)  \n pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)  \n pc : mt76_wcid_cleanup+0x84/0x22c [mt76]  \n lr : mt76_wcid_cleanup+0x64/0x22c [mt76]  \n sp : ffffffc00a803700  \n x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00  \n x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001  \n x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8  \n x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000  \n x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0  \n x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000  \n x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28  \n x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000  \n x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001  \n x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024  \n Call trace:  \n  mt76_wcid_cleanup+0x84/0x22c [mt76]  \n  __mt76_sta_remove+0x70/0xbc [mt76]  \n  mt76_sta_state+0x8c/0x1a4 [mt76]  \n  mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e]  \n  drv_sta_state+0x144/0x274 [mac80211]  \n  sta_info_move_state+0x1cc/0x2a4 [mac80211]  \n  sta_set_sinfo+0xaf8/0xc24 [mac80211]  \n  sta_info_destroy_addr_bss+0x4c/0x6c [mac80211]  \n  \n  ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211]  \n  cfg80211_check_station_change+0x1360/0x4710 [cfg80211]  \n  genl_family_rcv_msg_doit+0xb4/0x110  \n  genl_rcv_msg+0xd0/0x1bc  \n  netlink_rcv_skb+0x58/0x120  \n  genl_rcv+0x34/0x50  \n  netlink_unicast+0x1f0/0x2ec  \n  netlink_sendmsg+0x198/0x3d0  \n  ____sys_sendmsg+0x1b0/0x210  \n  ___sys_sendmsg+0x80/0xf0  \n  __sys_sendmsg+0x44/0xa0  \n  __arm64_sys_sendmsg+0x20/0x30  \n  invoke_syscall.constprop.0+0x4c/0xe0  \n  do_el0_svc+0x40/0xd0  \n  el0_svc+0x14/0x4c  \n  el0t_64_sync_handler+0x100/0x110  \n  el0t_64_sync+0x15c/0x160  \n Code: d2800002 910092c0 52800023 f9800011 (885f7c01)  \n ---[ end trace 7e42dd9a39ed2281 ]---  \n  \nFix by using mt76_dev_phy() which will map band_idx to the correct phy  \nfor all hardware combinations. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T15:10:39.000000Z"}, {"uuid": "3908c19f-0c2f-441b-b762-9cd07bccb702", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47718", "type": "seen", "source": "https://t.me/cvedetector/8454", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47718 - Realtek Technologies Wi-Fi Unauthorized Access Forgery\", \n  \"Content\": \"CVE ID : CVE-2024-47718 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nwifi: rtw88: always wait for both firmware loading attempts  \n  \nIn 'rtw_wait_firmware_completion()', always wait for both (regular and  \nwowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()'  \nhas failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue  \n'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually  \nthe wowlan one) is still in progress, causing UAF detected by KASAN. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T15:09:35.000000Z"}, {"uuid": "10fe82ba-a58b-421c-ae38-638182b934f2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47714", "type": "seen", "source": "https://t.me/cvedetector/8467", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47714 - Linux Kernel MT76 Wi-Fi Off-Path Stack Out-Of-Bounds WRITE\", \n  \"Content\": \"CVE ID : CVE-2024-47714 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nwifi: mt76: mt7996: use hweight16 to get correct tx antenna  \n  \nThe chainmask is u16 so using hweight8 cannot get correct tx_ant.  \nWithout this patch, the tx_ant of band 2 would be -1 and lead to the  \nfollowing issue:  \nBUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T15:09:52.000000Z"}, {"uuid": "ee57133d-16ff-41bb-bf63-65111d49a194", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47712", "type": "seen", "source": "https://t.me/cvedetector/8466", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47712 - Apache WiFi Device Use-After-Free RCU Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-47712 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nwifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param  \n  \nIn the `wilc_parse_join_bss_param` function, the TSF field of the `ies`  \nstructure is accessed after the RCU read-side critical section is  \nunlocked. According to RCU usage rules, this is illegal. Reusing this  \npointer can lead to unpredictable behavior, including accessing memory  \nthat has been updated or causing use-after-free issues.  \n  \nThis possible bug was identified using a static analysis tool developed  \nby myself, specifically designed to detect RCU-related issues.  \n  \nTo address this, the TSF value is now stored in a local variable  \n`ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is  \nthen assigned using this local variable, ensuring that the TSF value is  \nsafely accessed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T15:09:52.000000Z"}, {"uuid": "96eaa0d9-796c-4b49-857f-178f675783f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47711", "type": "seen", "source": "https://t.me/cvedetector/8464", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47711 - Here is a title for the vulnerability: \"MSV-SUSE-Vulnerability: Linux Unix/AF_UNIX Use-After-Free Vulnerability (VRF)\"\", \n  \"Content\": \"CVE ID : CVE-2024-47711 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \naf_unix: Don't return OOB skb in manage_oob().  \n  \nsyzbot reported use-after-free in unix_stream_recv_urg(). [0]  \n  \nThe scenario is  \n  \n  1. send(MSG_OOB)  \n  2. recv(MSG_OOB)  \n     -> The consumed OOB remains in recv queue  \n  3. send(MSG_OOB)  \n  4. recv()  \n     -> manage_oob() returns the next skb of the consumed OOB  \n     -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared  \n  5. recv(MSG_OOB)  \n     -> unix_sk(sk)->oob_skb is used but already freed  \n  \nThe recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB  \nskb.\") uncovered the issue.  \n  \nIf the OOB skb is consumed and the next skb is peeked in manage_oob(),  \nwe still need to check if the skb is OOB.  \n  \nLet's do so by falling back to the following checks in manage_oob()  \nand add the test case in selftest.  \n  \nNote that we need to add a similar check for SIOCATMARK.  \n  \n[0]:  \nBUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959  \nRead of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235  \n  \nCPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0  \nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024  \nCall Trace:  \n   \n __dump_stack lib/dump_stack.c:93 [inline]  \n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  \n print_address_description mm/kasan/report.c:377 [inline]  \n print_report+0x169/0x550 mm/kasan/report.c:488  \n kasan_report+0x143/0x180 mm/kasan/report.c:601  \n unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959  \n unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640  \n unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778  \n unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996  \n sock_recvmsg_nosec net/socket.c:1046 [inline]  \n sock_recvmsg+0x22f/0x280 net/socket.c:1068  \n ____sys_recvmsg+0x1db/0x470 net/socket.c:2816  \n ___sys_recvmsg net/socket.c:2858 [inline]  \n __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888  \n do_syscall_x64 arch/x86/entry/common.c:52 [inline]  \n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  \n entry_SYSCALL_64_after_hwframe+0x77/0x7f  \nRIP: 0033:0x7f5360d6b4e9  \nCode: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <483d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48  \nRSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f  \nRAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9  \nRDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003  \nRBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000  \nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001  \nR13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001  \n   \n  \nAllocated by task 5235:  \n kasan_save_stack mm/kasan/common.c:47 [inline]  \n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  \n unpoison_slab_object mm/kasan/common.c:312 [inline]  \n __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338  \n kasan_slab_alloc include/linux/kasan.h:201 [inline]  \n slab_post_alloc_hook mm/slub.c:3988 [inline]  \n slab_alloc_node mm/slub.c:4037 [inline]  \n kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080  \n __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667  \n alloc_skb include/linux/skbuff.h:1320 [inline]  \n alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528  \n sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815  \n sock_alloc_send_skb include/net/sock.h:1778 [inline]  \n queue_oob+0x108/0x680 net/unix/af_unix.c:2198  \n unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351  \n sock_sendmsg_nosec net/socket.c:730 [inline]  \n __sock_sendmsg+[...]", "creation_timestamp": "2024-10-21T15:09:50.000000Z"}, {"uuid": "c4456b93-5570-4a51-9a9a-9f237d303761", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47710", "type": "seen", "source": "https://t.me/cvedetector/8463", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47710 - Linux kernel Soft Lockup in Sock Map Hash Free\", \n  \"Content\": \"CVE ID : CVE-2024-47710 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsock_map: Add a cond_resched() in sock_hash_free()  \n  \nSeveral syzbot soft lockup reports all have in common sock_hash_free()  \n  \nIf a map with a large number of buckets is destroyed, we need to yield  \nthe cpu when needed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T15:09:46.000000Z"}, {"uuid": "47581dac-1ef6-4676-97b1-00b5c4e0ea1f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47713", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "d590bd04-bee7-4770-b8fb-d7b9ed07080e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47716", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/8473", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47716 - Raspberry Pi ARM VFP Use-After-Free Memory Corruption\", \n  \"Content\": \"CVE ID : CVE-2024-47716 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros  \n  \nFloating point instructions in userspace can crash some arm kernels  \nbuilt with clang/LLD 17.0.6:  \n  \n    BUG: unsupported FP instruction in kernel mode  \n    FPEXC == 0xc0000780  \n    Internal error: Oops - undefined instruction: 0 [#1] ARM  \n    CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1  \n    Hardware name: BCM2835  \n    PC is at vfp_support_entry+0xc8/0x2cc  \n    LR is at do_undefinstr+0xa8/0x250  \n    pc : []    lr : []    psr: a0000013  \n    sp : dc8d1f68  ip : 60000013  fp : bedea19c  \n    r10: ec532b17  r9 : 00000010  r8 : 0044766c  \n    r7 : c0000780  r6 : ec532b17  r5 : c1c13800  r4 : dc8d1fb0  \n    r3 : c10072c4  r2 : c0101c88  r1 : ec532b17  r0 : 0044766c  \n    Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none  \n    Control: 00c5387d  Table: 0251c008  DAC: 00000051  \n    Register r0 information: non-paged memory  \n    Register r1 information: vmalloc memory  \n    Register r2 information: non-slab/vmalloc memory  \n    Register r3 information: non-slab/vmalloc memory  \n    Register r4 information: 2-page vmalloc region  \n    Register r5 information: slab kmalloc-cg-2k  \n    Register r6 information: vmalloc memory  \n    Register r7 information: non-slab/vmalloc memory  \n    Register r8 information: non-paged memory  \n    Register r9 information: zero-size pointer  \n    Register r10 information: vmalloc memory  \n    Register r11 information: non-paged memory  \n    Register r12 information: non-paged memory  \n    Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b)  \n    Stack: (0xdc8d1f68 to 0xdc8d2000)  \n    1f60:                   0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0  \n    1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010  \n    1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188  \n    1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c  \n    1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000  \n    Call trace:  \n    [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250)  \n    [] (do_undefinstr) from [] (__und_usr+0x70/0x80)  \n    Exception stack(0xdc8d1fb0 to 0xdc8d1ff8)  \n    1fa0:                                     b6f68af8 00448fc0 00000000 bedea188  \n    1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c  \n    1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff  \n    Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10)  \n    ---[ end trace 0000000000000000 ]---  \n    Kernel panic - not syncing: Fatal exception in interrupt  \n    ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---  \n  \nThis is a minimal userspace reproducer on a Raspberry Pi Zero W:  \n  \n    #include   \n    #include   \n  \n    int main(void)  \n    {  \n            double v = 1.0;  \n            printf(\"%fn\", NAN + *(volatile double *)&v);  \n            return 0;  \n    }  \n  \nAnother way to consistently trigger the oops is:  \n  \n    calvin@raspberry-pi-zero-w ~$ python -c \"import json\"  \n  \nThe bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n,  \nbecause the pr_debug() calls act as barriers even when not activated.  \n  \nThis is the output from the same kernel source built with the same  \ncompiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as  \nexpected:  \n  \n    VFP: bounce: trigger ec532b17 fpexc c0000780  \n    VFP: emulate: INST=0xee377b06 SCR=0x00000000  \n    VFP: bounce: trigger eef1fa10 fpexc c0000780  \n    VFP: emulate: INST=0xeeb40b40 SCR=0x00000000  \n    VFP: raising exceptions 30000000  \n  \n    calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer  \n    nan  \n  \nCrudely grepping for vmsr/vmrs instruct[...]", "creation_timestamp": "2024-10-21T15:10:01.000000Z"}, {"uuid": "40cd3f68-e45d-43ae-ad3b-7c4ff7345ef3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47719", "type": "seen", "source": "https://t.me/cvedetector/8458", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-47719 - Linux iommufd huge automatic alignment overflow vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-47719 \nPublished : Oct. 21, 2024, 12:15 p.m. | 41\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \niommufd: Protect against overflow of ALIGN() during iova allocation  \n  \nUserspace can supply an iova and uptr such that the target iova alignment  \nbecomes really big and ALIGN() overflows which corrupts the selected area  \nrange during allocation. CONFIG_IOMMUFD_TEST can detect this:  \n  \n   WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]  \n   WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352  \n   Modules linked in:  \n   CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0  \n   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024  \n   RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline]  \n   RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352  \n   Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38  \n   RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293  \n   RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00  \n   RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000  \n   RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942  \n   R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010  \n   R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00  \n   FS:  000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000  \n   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n   CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0  \n   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \n   Call Trace:  \n      \n    iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274  \n    iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421  \n    vfs_ioctl fs/ioctl.c:51 [inline]  \n    __do_sys_ioctl fs/ioctl.c:907 [inline]  \n    __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  \n    do_syscall_x64 arch/x86/entry/common.c:52 [inline]  \n    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  \n    entry_SYSCALL_64_after_hwframe+0x77/0x7f  \n  \nCap the automatic alignment to the huge page size, which is probably a  \nbetter idea overall. Huge automatic alignments can fragment and chew up  \nthe available IOVA space without any reason. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"21 Oct 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-10-21T15:09:39.000000Z"}, {"uuid": "d664baa3-e587-4435-800e-b020fe6658c9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47718", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "09fcb534-e182-4356-a430-ca78bbb8ae06", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47712", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "ee39fc4b-d669-4a32-a358-e8488b4e6371", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-47710", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}]}