Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: ensure snd_nxt is properly initialized on connect<br /> <br /> Christoph reported a splat hinting at a corrupted snd_una:<br /> <br /> WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005<br /> Modules linked in:<br /> CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> Workqueue: events mptcp_worker<br /> RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005<br /> Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8<br /> 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe<br /> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9<br /> RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4<br /> RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000<br /> R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000<br /> FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0<br /> Call Trace:<br /> <br /> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]<br /> mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]<br /> __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615<br /> mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767<br /> process_one_work+0x1e0/0x560 kernel/workqueue.c:3254<br /> process_scheduled_works kernel/workqueue.c:3335 [inline]<br /> worker_thread+0x3c7/0x640 kernel/workqueue.c:3416<br /> kthread+0x121/0x170 kernel/kthread.c:388<br /> ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243<br /> <br /> <br /> When fallback to TCP happens early on a client socket, snd_nxt<br /> is not yet initialized and any incoming ack will copy such value<br /> into snd_una. If the mptcp worker (dumbly) tries mptcp-level<br /> re-injection after such ack, that would unconditionally trigger a send<br /> buffer cleanup using &amp;#39;bad&amp;#39; snd_una values.<br /> <br /> We could easily disable re-injection for fallback sockets, but such<br /> dumb behavior already helped catching a few subtle issues and a very<br /> low to zero impact in practice.<br /> <br /> Instead address the issue always initializing snd_nxt (and write_seq,<br /> for consistency) at connect time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix UAF in error path<br /> <br /> Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported<br /> a UAF in the tipc_buf_append() error path:<br /> <br /> BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0<br /> linux/net/core/skbuff.c:1183<br /> Read of size 8 at addr ffff88804d2a7c80 by task poc/8034<br /> <br /> CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.0-debian-1.16.0-5 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack linux/lib/dump_stack.c:88<br /> dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106<br /> print_address_description linux/mm/kasan/report.c:377<br /> print_report+0xc4/0x620 linux/mm/kasan/report.c:488<br /> kasan_report+0xda/0x110 linux/mm/kasan/report.c:601<br /> kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183<br /> skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026<br /> skb_release_all linux/net/core/skbuff.c:1094<br /> __kfree_skb linux/net/core/skbuff.c:1108<br /> kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144<br /> kfree_skb linux/./include/linux/skbuff.h:1244<br /> tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186<br /> tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324<br /> tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824<br /> tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159<br /> tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390<br /> udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108<br /> udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186<br /> udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346<br /> __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422<br /> ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233<br /> NF_HOOK linux/./include/linux/netfilter.h:314<br /> NF_HOOK linux/./include/linux/netfilter.h:308<br /> ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254<br /> dst_input linux/./include/net/dst.h:461<br /> ip_rcv_finish linux/net/ipv4/ip_input.c:449<br /> NF_HOOK linux/./include/linux/netfilter.h:314<br /> NF_HOOK linux/./include/linux/netfilter.h:308<br /> ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534<br /> __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648<br /> process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976<br /> __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576<br /> napi_poll linux/net/core/dev.c:6645<br /> net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781<br /> __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553<br /> do_softirq linux/kernel/softirq.c:454<br /> do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441<br /> <br /> <br /> __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381<br /> local_bh_enable linux/./include/linux/bottom_half.h:33<br /> rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851<br /> __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378<br /> dev_queue_xmit linux/./include/linux/netdevice.h:3169<br /> neigh_hh_output linux/./include/net/neighbour.h:526<br /> neigh_output linux/./include/net/neighbour.h:540<br /> ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235<br /> __ip_finish_output linux/net/ipv4/ip_output.c:313<br /> __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295<br /> ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323<br /> NF_HOOK_COND linux/./include/linux/netfilter.h:303<br /> ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433<br /> dst_output linux/./include/net/dst.h:451<br /> ip_local_out linux/net/ipv4/ip_output.c:129<br /> ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492<br /> udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963<br /> udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250<br /> inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850<br /> sock_sendmsg_nosec linux/net/socket.c:730<br /> __sock_sendmsg linux/net/socket.c:745<br /> __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191<br /> __do_sys_sendto linux/net/socket.c:2203<br /> __se_sys_sendto linux/net/socket.c:2199<br /> __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199<br /> do_syscall_x64 linux/arch/x86/entry/common.c:52<br /> do_syscall_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer<br /> <br /> Btrfs clears the content of an extent buffer marked as<br /> EXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is<br /> introduced to prevent a write hole of an extent buffer, which is once<br /> allocated, marked dirty, but turns out unnecessary and cleaned up within<br /> one transaction operation.<br /> <br /> Currently, btrfs_clear_buffer_dirty() marks the extent buffer as<br /> EXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call<br /> happens while the buffer is under IO (with the WRITEBACK flag set,<br /> without the DIRTY flag), we can add the ZEROOUT flag and clear the<br /> buffer&amp;#39;s content just before a bio submission. As a result:<br /> <br /> 1) it can lead to adding faulty delayed reference item which leads to a<br /> FS corrupted (EUCLEAN) error, and<br /> <br /> 2) it writes out cleared tree node on disk<br /> <br /> The former issue is previously discussed in [1]. The corruption happens<br /> when it runs a delayed reference update. So, on-disk data is safe.<br /> <br /> [1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/<br /> <br /> The latter one can reach on-disk data. But, as that node is already<br /> processed by btrfs_clear_buffer_dirty(), that will be invalidated in the<br /> next transaction commit anyway. So, the chance of hitting the corruption<br /> is relatively small.<br /> <br /> Anyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to<br /> keep the content under IO intact.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()<br /> <br /> When I did memory failure tests recently, below warning occurs:<br /> <br /> DEBUG_LOCKS_WARN_ON(1)<br /> WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0<br /> Modules linked in: mce_inject hwpoison_inject<br /> CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__lock_acquire+0xccb/0x1ca0<br /> RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082<br /> RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8<br /> RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0<br /> RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb<br /> R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10<br /> R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004<br /> FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> lock_acquire+0xbe/0x2d0<br /> _raw_spin_lock_irqsave+0x3a/0x60<br /> hugepage_subpool_put_pages.part.0+0xe/0xc0<br /> free_huge_folio+0x253/0x3f0<br /> dissolve_free_huge_page+0x147/0x210<br /> __page_handle_poison+0x9/0x70<br /> memory_failure+0x4e6/0x8c0<br /> hard_offline_page_store+0x55/0xa0<br /> kernfs_fop_write_iter+0x12c/0x1d0<br /> vfs_write+0x380/0x540<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xbc/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff9f3114887<br /> RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887<br /> RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001<br /> RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c<br /> R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00<br /> <br /> Kernel panic - not syncing: kernel: panic_on_warn set ...<br /> CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> panic+0x326/0x350<br /> check_panic_on_warn+0x4f/0x50<br /> __warn+0x98/0x190<br /> report_bug+0x18e/0x1a0<br /> handle_bug+0x3d/0x70<br /> exc_invalid_op+0x18/0x70<br /> asm_exc_invalid_op+0x1a/0x20<br /> RIP: 0010:__lock_acquire+0xccb/0x1ca0<br /> RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082<br /> RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8<br /> RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0<br /> RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb<br /> R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10<br /> R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004<br /> lock_acquire+0xbe/0x2d0<br /> _raw_spin_lock_irqsave+0x3a/0x60<br /> hugepage_subpool_put_pages.part.0+0xe/0xc0<br /> free_huge_folio+0x253/0x3f0<br /> dissolve_free_huge_page+0x147/0x210<br /> __page_handle_poison+0x9/0x70<br /> memory_failure+0x4e6/0x8c0<br /> hard_offline_page_store+0x55/0xa0<br /> kernfs_fop_write_iter+0x12c/0x1d0<br /> vfs_write+0x380/0x540<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xbc/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff9f3114887<br /> RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887<br /> RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001<br /> RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c<br /> R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00<br /> <br /> <br /> After git bisecting and digging into the code, I believe the root cause is<br /> that _deferred_list field of folio is unioned with _hugetlb_subpool field.<br /> In __update_and_free_hugetlb_folio(), folio-&gt;_deferred_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdhci-msm: pervent access to suspended controller<br /> <br /> Generic sdhci code registers LED device and uses host-&gt;runtime_suspended<br /> flag to protect access to it. The sdhci-msm driver doesn&amp;#39;t set this flag,<br /> which causes a crash when LED is accessed while controller is runtime<br /> suspended. Fix this by setting the flag correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: fix the double free in rvu_npc_freemem()<br /> <br /> Clang static checker(scan-build) warning：<br /> drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:line 2184, column 2<br /> Attempt to free released memory.<br /> <br /> npc_mcam_rsrcs_deinit() has released &amp;#39;mcam-&gt;counters.bmap&amp;#39;. Deleted this<br /> redundant kfree() to fix this double free problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: fix info leak when fetching fw build id<br /> <br /> Add the missing sanity checks and move the 255-byte build-id buffer off<br /> the stack to avoid leaking stack data through debugfs in case the<br /> build-info reply is malformed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: fix info leak when fetching board id<br /> <br /> Add the missing sanity check when fetching the board id to avoid leaking<br /> slab data when later requesting the firmware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: qca: add missing firmware sanity checks<br /> <br /> Add the missing sanity checks when parsing the firmware files before<br /> downloading them to avoid accessing and corrupting memory beyond the<br /> vmalloced buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/userfaultfd: reset ptes when close() for wr-protected ones<br /> <br /> Userfaultfd unregister includes a step to remove wr-protect bits from all<br /> the relevant pgtable entries, but that only covered an explicit<br /> UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover<br /> that too. This fixes a WARN trace.<br /> <br /> The only user visible side effect is the user can observe leftover<br /> wr-protect bits even if the user close()ed on an userfaultfd when<br /> releasing the last reference of it. However hopefully that should be<br /> harmless, and nothing bad should happen even if so.<br /> <br /> This change is now more important after the recent page-table-check<br /> patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check:<br /> support userfault wr-protect entries")), as we&amp;#39;ll do sanity check on<br /> uffd-wp bits without vma context. So it&amp;#39;s better if we can 100%<br /> guarantee no uffd-wp bit leftovers, to make sure each report will be<br /> valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: use memalloc_nofs_save() in page_cache_ra_order()<br /> <br /> See commit f2c817bed58d ("mm: use memalloc_nofs_save in readahead path"),<br /> ensure that page_cache_ra_order() do not attempt to reclaim file-backed<br /> pages too, or it leads to a deadlock, found issue when test ext4 large<br /> folio.<br /> <br /> INFO: task DataXceiver for:7494 blocked for more than 120 seconds.<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200<br /> Call trace:<br /> __switch_to+0x14c/0x240<br /> __schedule+0x82c/0xdd0<br /> schedule+0x58/0xf0<br /> io_schedule+0x24/0xa0<br /> __folio_lock+0x130/0x300<br /> migrate_pages_batch+0x378/0x918<br /> migrate_pages+0x350/0x700<br /> compact_zone+0x63c/0xb38<br /> compact_zone_order+0xc0/0x118<br /> try_to_compact_pages+0xb0/0x280<br /> __alloc_pages_direct_compact+0x98/0x248<br /> __alloc_pages+0x510/0x1110<br /> alloc_pages+0x9c/0x130<br /> folio_alloc+0x20/0x78<br /> filemap_alloc_folio+0x8c/0x1b0<br /> page_cache_ra_order+0x174/0x308<br /> ondemand_readahead+0x1c8/0x2b8<br /> page_cache_async_ra+0x68/0xb8<br /> filemap_readahead.isra.0+0x64/0xa8<br /> filemap_get_pages+0x3fc/0x5b0<br /> filemap_splice_read+0xf4/0x280<br /> ext4_file_splice_read+0x2c/0x48 [ext4]<br /> vfs_splice_read.part.0+0xa8/0x118<br /> splice_direct_to_actor+0xbc/0x288<br /> do_splice_direct+0x9c/0x108<br /> do_sendfile+0x328/0x468<br /> __arm64_sys_sendfile64+0x8c/0x148<br /> invoke_syscall+0x4c/0x118<br /> el0_svc_common.constprop.0+0xc8/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x4c/0x1f8<br /> el0t_64_sync_handler+0xc0/0xc8<br /> el0t_64_sync+0x188/0x190

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()<br /> <br /> This was missed because of the function pointer indirection.<br /> <br /> nvidia_smmu_context_fault() is also installed as a irq function, and the<br /> &amp;#39;void *&amp;#39; was changed to a struct arm_smmu_domain. Since the iommu_domain<br /> is embedded at a non-zero offset this causes nvidia_smmu_context_fault()<br /> to miscompute the offset. Fixup the types.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000<br /> [0000000000000120] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> Modules linked in:<br /> CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1<br /> Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023<br /> Workqueue: events_unbound deferred_probe_work_func<br /> pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : nvidia_smmu_context_fault+0x1c/0x158<br /> lr : __free_irq+0x1d4/0x2e8<br /> sp : ffff80008044b6f0<br /> x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970<br /> x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30<br /> x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000<br /> x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff<br /> x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888<br /> x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0<br /> x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c<br /> x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f<br /> x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000<br /> x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057<br /> Call trace:<br /> nvidia_smmu_context_fault+0x1c/0x158<br /> __free_irq+0x1d4/0x2e8<br /> free_irq+0x3c/0x80<br /> devm_free_irq+0x64/0xa8<br /> arm_smmu_domain_free+0xc4/0x158<br /> iommu_domain_free+0x44/0xa0<br /> iommu_deinit_device+0xd0/0xf8<br /> __iommu_group_remove_device+0xcc/0xe0<br /> iommu_bus_notifier+0x64/0xa8<br /> notifier_call_chain+0x78/0x148<br /> blocking_notifier_call_chain+0x4c/0x90<br /> bus_notify+0x44/0x70<br /> device_del+0x264/0x3e8<br /> pci_remove_bus_device+0x84/0x120<br /> pci_remove_root_bus+0x5c/0xc0<br /> dw_pcie_host_deinit+0x38/0xe0<br /> tegra_pcie_config_rp+0xc0/0x1f0<br /> tegra_pcie_dw_probe+0x34c/0x700<br /> platform_probe+0x70/0xe8<br /> really_probe+0xc8/0x3a0<br /> __driver_probe_device+0x84/0x160<br /> driver_probe_device+0x44/0x130<br /> __device_attach_driver+0xc4/0x170<br /> bus_for_each_drv+0x90/0x100<br /> __device_attach+0xa8/0x1c8<br /> device_initial_probe+0x1c/0x30<br /> bus_probe_device+0xb0/0xc0<br /> deferred_probe_work_func+0xbc/0x120<br /> process_one_work+0x194/0x490<br /> worker_thread+0x284/0x3b0<br /> kthread+0xf4/0x108<br /> ret_from_fork+0x10/0x20<br /> Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1)