Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uprobes: Reject the shared zeropage in uprobe_write_opcode()<br /> <br /> We triggered the following crash in syzkaller tests:<br /> <br /> BUG: Bad page state in process syz.7.38 pfn:1eff3<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3<br /> flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)<br /> raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000<br /> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> bad_page+0x69/0xf0<br /> free_unref_page_prepare+0x401/0x500<br /> free_unref_page+0x6d/0x1b0<br /> uprobe_write_opcode+0x460/0x8e0<br /> install_breakpoint.part.0+0x51/0x80<br /> register_for_each_vma+0x1d9/0x2b0<br /> __uprobe_register+0x245/0x300<br /> bpf_uprobe_multi_link_attach+0x29b/0x4f0<br /> link_create+0x1e2/0x280<br /> __sys_bpf+0x75f/0xac0<br /> __x64_sys_bpf+0x1a/0x30<br /> do_syscall_64+0x56/0x100<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1<br /> <br /> The following syzkaller test case can be used to reproduce:<br /> <br /> r2 = creat(&amp;(0x7f0000000000)=&amp;#39;./file0\x00&amp;#39;, 0x8)<br /> write$nbd(r2, &amp;(0x7f0000000580)=ANY=[], 0x10)<br /> r4 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)=&amp;#39;./file0\x00&amp;#39;, 0x42, 0x0)<br /> mmap$IORING_OFF_SQ_RING(&amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)<br /> r5 = userfaultfd(0x80801)<br /> ioctl$UFFDIO_API(r5, 0xc018aa3f, &amp;(0x7f0000000040)={0xaa, 0x20})<br /> r6 = userfaultfd(0x80801)<br /> ioctl$UFFDIO_API(r6, 0xc018aa3f, &amp;(0x7f0000000140))<br /> ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &amp;(0x7f0000000100)={{&amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})<br /> ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &amp;(0x7f0000000000)={{&amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})<br /> r7 = bpf$PROG_LOAD(0x5, &amp;(0x7f0000000140)={0x2, 0x3, &amp;(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &amp;(0x7f0000000000)=&amp;#39;GPL\x00&amp;#39;, 0x7, 0x0, 0x0, 0x0, 0x0, &amp;#39;\x00&amp;#39;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)<br /> bpf$BPF_LINK_CREATE_XDP(0x1c, &amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&amp;(0x7f0000000080)=&amp;#39;./file0\x00&amp;#39;, &amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)<br /> <br /> The cause is that zero pfn is set to the PTE without increasing the RSS<br /> count in mfill_atomic_pte_zeropage() and the refcount of zero folio does<br /> not increase accordingly. Then, the operation on the same pfn is performed<br /> in uprobe_write_opcode()-&gt;__replace_page() to unconditional decrease the<br /> RSS count and old_folio&amp;#39;s refcount.<br /> <br /> Therefore, two bugs are introduced:<br /> <br /> 1. The RSS count is incorrect, when process exit, the check_mm() report<br /> error "Bad rss-count".<br /> <br /> 2. The reserved folio (zero folio) is freed when folio-&gt;refcount is zero,<br /> then free_pages_prepare-&gt;free_page_is_bad() report error<br /> "Bad page state".<br /> <br /> There is more, the following warning could also theoretically be triggered:<br /> <br /> __replace_page()<br /> -&gt; ...<br /> -&gt; folio_remove_rmap_pte()<br /> -&gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)<br /> <br /> Considering that uprobe hit on the zero folio is a very rare case, just<br /> reject zero old folio immediately after get_user_page_vma_remote().<br /> <br /> [ mingo: Cleaned up the changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up<br /> <br /> The issue was caused by dput(upper) being called before<br /> ovl_dentry_update_reval(), while upper-&gt;d_flags was still<br /> accessed in ovl_dentry_remote().<br /> <br /> Move dput(upper) after its last use to prevent use-after-free.<br /> <br /> BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]<br /> BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc3/0x620 mm/kasan/report.c:488<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> ovl_dentry_remote fs/overlayfs/util.c:162 [inline]<br /> ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167<br /> ovl_link_up fs/overlayfs/copy_up.c:610 [inline]<br /> ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170<br /> ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223<br /> ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136<br /> vfs_rename+0xf84/0x20a0 fs/namei.c:4893<br /> ...<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix suspicious RCU usage<br /> <br /> Commit ("iommu/vt-d: Allocate DMAR fault interrupts<br /> locally") moved the call to enable_drhd_fault_handling() to a code<br /> path that does not hold any lock while traversing the drhd list. Fix<br /> it by ensuring the dmar_global_lock lock is held when traversing the<br /> drhd list.<br /> <br /> Without this fix, the following warning is triggered:<br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.14.0-rc3 #55 Not tainted<br /> -----------------------------<br /> drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!!<br /> other info that might help us debug this:<br /> rcu_scheduler_active = 1, debug_locks = 1<br /> 2 locks held by cpuhp/1/23:<br /> #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0<br /> #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0<br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xb7/0xd0<br /> lockdep_rcu_suspicious+0x159/0x1f0<br /> ? __pfx_enable_drhd_fault_handling+0x10/0x10<br /> enable_drhd_fault_handling+0x151/0x180<br /> cpuhp_invoke_callback+0x1df/0x990<br /> cpuhp_thread_fun+0x1ea/0x2c0<br /> smpboot_thread_fn+0x1f5/0x2e0<br /> ? __pfx_smpboot_thread_fn+0x10/0x10<br /> kthread+0x12a/0x2d0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x4a/0x60<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat<br /> about a possible deadlock between dmar_global_lock and cpu_hotplug_lock.<br /> This is avoided by not holding dmar_global_lock when calling<br /> iommu_device_register(), which initiates the device probe process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-integrity: Avoid divide by zero in table status in Inline mode<br /> <br /> In Inline mode, the journal is unused, and journal_sectors is zero.<br /> <br /> Calculating the journal watermark requires dividing by journal_sectors,<br /> which should be done only if the journal is configured.<br /> <br /> Otherwise, a simple table query (dmsetup table) can cause OOPS.<br /> <br /> This bug did not show on some systems, perhaps only due to<br /> compiler optimization.<br /> <br /> On my 32-bit testing machine, this reliably crashes with the following:<br /> <br /> : Oops: divide error: 0000 [#1] PREEMPT SMP<br /> : CPU: 0 UID: 0 PID: 2450 Comm: dmsetup Not tainted 6.14.0-rc2+ #959<br /> : EIP: dm_integrity_status+0x2f8/0xab0 [dm_integrity]<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: bsg: Fix crash when arpmb command fails<br /> <br /> If the device doesn&amp;#39;t support arpmb we&amp;#39;ll crash due to copying user data in<br /> bsg_transport_sg_io_fn().<br /> <br /> In the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do not<br /> set the job&amp;#39;s reply_len.<br /> <br /> Memory crash backtrace:<br /> 3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22<br /> <br /> 4,1308,531166555,-;Call Trace:<br /> <br /> 4,1309,531166559,-; <br /> <br /> 4,1310,531166565,-; ? show_regs+0x6d/0x80<br /> <br /> 4,1311,531166575,-; ? die+0x37/0xa0<br /> <br /> 4,1312,531166583,-; ? do_trap+0xd4/0xf0<br /> <br /> 4,1313,531166593,-; ? do_error_trap+0x71/0xb0<br /> <br /> 4,1314,531166601,-; ? usercopy_abort+0x6c/0x80<br /> <br /> 4,1315,531166610,-; ? exc_invalid_op+0x52/0x80<br /> <br /> 4,1316,531166622,-; ? usercopy_abort+0x6c/0x80<br /> <br /> 4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20<br /> <br /> 4,1318,531166643,-; ? usercopy_abort+0x6c/0x80<br /> <br /> 4,1319,531166652,-; __check_heap_object+0xe3/0x120<br /> <br /> 4,1320,531166661,-; check_heap_object+0x185/0x1d0<br /> <br /> 4,1321,531166670,-; __check_object_size.part.0+0x72/0x150<br /> <br /> 4,1322,531166679,-; __check_object_size+0x23/0x30<br /> <br /> 4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/userptr: fix EFAULT handling<br /> <br /> Currently we treat EFAULT from hmm_range_fault() as a non-fatal error<br /> when called from xe_vm_userptr_pin() with the idea that we want to avoid<br /> killing the entire vm and chucking an error, under the assumption that<br /> the user just did an unmap or something, and has no intention of<br /> actually touching that memory from the GPU. At this point we have<br /> already zapped the PTEs so any access should generate a page fault, and<br /> if the pin fails there also it will then become fatal.<br /> <br /> However it looks like it&amp;#39;s possible for the userptr vma to still be on<br /> the rebind list in preempt_rebind_work_func(), if we had to retry the<br /> pin again due to something happening in the caller before we did the<br /> rebind step, but in the meantime needing to re-validate the userptr and<br /> this time hitting the EFAULT.<br /> <br /> This explains an internal user report of hitting:<br /> <br /> [ 191.738349] WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xe_res_cursor.h:158 xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]<br /> [ 191.738551] Workqueue: xe-ordered-wq preempt_rebind_work_func [xe]<br /> [ 191.738616] RIP: 0010:xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]<br /> [ 191.738690] Call Trace:<br /> [ 191.738692] <br /> [ 191.738694] ? show_regs+0x69/0x80<br /> [ 191.738698] ? __warn+0x93/0x1a0<br /> [ 191.738703] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]<br /> [ 191.738759] ? report_bug+0x18f/0x1a0<br /> [ 191.738764] ? handle_bug+0x63/0xa0<br /> [ 191.738767] ? exc_invalid_op+0x19/0x70<br /> [ 191.738770] ? asm_exc_invalid_op+0x1b/0x20<br /> [ 191.738777] ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]<br /> [ 191.738834] ? ret_from_fork_asm+0x1a/0x30<br /> [ 191.738849] bind_op_prepare+0x105/0x7b0 [xe]<br /> [ 191.738906] ? dma_resv_reserve_fences+0x301/0x380<br /> [ 191.738912] xe_pt_update_ops_prepare+0x28c/0x4b0 [xe]<br /> [ 191.738966] ? kmemleak_alloc+0x4b/0x80<br /> [ 191.738973] ops_execute+0x188/0x9d0 [xe]<br /> [ 191.739036] xe_vm_rebind+0x4ce/0x5a0 [xe]<br /> [ 191.739098] ? trace_hardirqs_on+0x4d/0x60<br /> [ 191.739112] preempt_rebind_work_func+0x76f/0xd00 [xe]<br /> <br /> Followed by NPD, when running some workload, since the sg was never<br /> actually populated but the vma is still marked for rebind when it should<br /> be skipped for this special EFAULT case. This is confirmed to fix the<br /> user report.<br /> <br /> v2 (MattB):<br /> - Move earlier.<br /> v3 (MattB):<br /> - Update the commit message to make it clear that this indeed fixes the<br /> issue.<br /> <br /> (cherry picked from commit 6b93cb98910c826c2e2004942f8b060311e43618)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free on inode when scanning root during em shrinking<br /> <br /> At btrfs_scan_root() we are accessing the inode&amp;#39;s root (and fs_info) in a<br /> call to btrfs_fs_closing() after we have scheduled the inode for a delayed<br /> iput, and that can result in a use-after-free on the inode in case the<br /> cleaner kthread does the iput before we dereference the inode in the call<br /> to btrfs_fs_closing().<br /> <br /> Fix this by using the fs_info stored already in a local variable instead<br /> of doing inode-&gt;root-&gt;fs_info.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: always handle address removal under msk socket lock<br /> <br /> Syzkaller reported a lockdep splat in the PM control path:<br /> <br /> WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline]<br /> WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline]<br /> WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024<br /> RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline]<br /> RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline]<br /> RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788<br /> Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff<br /> RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283<br /> RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000<br /> RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408<br /> RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000<br /> R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0<br /> R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00<br /> FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59<br /> mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486<br /> mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline]<br /> mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]<br /> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348<br /> netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892<br /> sock_sendmsg_nosec net/socket.c:718 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:733<br /> ____sys_sendmsg+0x53a/0x860 net/socket.c:2573<br /> ___sys_sendmsg net/socket.c:2627 [inline]<br /> __sys_sendmsg+0x269/0x350 net/socket.c:2659<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f7e9998cde9<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9<br /> RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007<br /> RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088<br /> <br /> Indeed the PM can try to send a RM_ADDR over a msk without acquiring<br /> first the msk socket lock.<br /> <br /> The bugged code-path comes from an early optimization: when there<br /> are no subflows, the PM should (usually) not send RM_ADDR<br /> notifications.<br /> <br /> The above statement is incorrect, as without locks another process<br /> could concur<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: gl620a: fix endpoint checking in genelink_bind()<br /> <br /> Syzbot reports [1] a warning in usb_submit_urb() triggered by<br /> inconsistencies between expected and actually present endpoints<br /> in gl620a driver. Since genelink_bind() does not properly<br /> verify whether specified eps are in fact provided by the device,<br /> in this case, an artificially manufactured one, one may get a<br /> mismatch.<br /> <br /> Fix the issue by resorting to a usbnet utility function<br /> usbnet_get_endpoints(), usually reserved for this very problem.<br /> Check for endpoints and return early before proceeding further if<br /> any are missing.<br /> <br /> [1] Syzbot report:<br /> usb 5-1: Manufacturer: syz<br /> usb 5-1: SerialNumber: syz<br /> usb 5-1: config 0 descriptor??<br /> gl620a 5-1:0.23 usb0: register &amp;#39;gl620a&amp;#39; at usb-dummy_hcd.0-1, ...<br /> ------------[ cut here ]------------<br /> usb 5-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503<br /> ...<br /> Call Trace:<br /> <br /> usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467<br /> __netdev_start_xmit include/linux/netdevice.h:5002 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5011 [inline]<br /> xmit_one net/core/dev.c:3590 [inline]<br /> dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606<br /> sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343<br /> __dev_xmit_skb net/core/dev.c:3827 [inline]<br /> __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400<br /> dev_queue_xmit include/linux/netdevice.h:3168 [inline]<br /> neigh_resolve_output net/core/neighbour.c:1514 [inline]<br /> neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494<br /> neigh_output include/net/neighbour.h:539 [inline]<br /> ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141<br /> __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]<br /> ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226<br /> NF_HOOK_COND include/linux/netfilter.h:303 [inline]<br /> ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247<br /> dst_output include/net/dst.h:450 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> NF_HOOK include/linux/netfilter.h:308 [inline]<br /> mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819<br /> mld_send_cr net/ipv6/mcast.c:2120 [inline]<br /> mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651<br /> process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229<br /> process_scheduled_works kernel/workqueue.c:3310 [inline]<br /> worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: npcm: disable interrupt enable bit before devm_request_irq<br /> <br /> The customer reports that there is a soft lockup issue related to<br /> the i2c driver. After checking, the i2c module was doing a tx transfer<br /> and the bmc machine reboots in the middle of the i2c transaction, the i2c<br /> module keeps the status without being reset.<br /> <br /> Due to such an i2c module status, the i2c irq handler keeps getting<br /> triggered since the i2c irq handler is registered in the kernel booting<br /> process after the bmc machine is doing a warm rebooting.<br /> The continuous triggering is stopped by the soft lockup watchdog timer.<br /> <br /> Disable the interrupt enable bit in the i2c module before calling<br /> devm_request_irq to fix this issue since the i2c relative status bit<br /> is read-only.<br /> <br /> Here is the soft lockup log.<br /> [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1]<br /> [ 28.183351] Modules linked in:<br /> [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1<br /> [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 28.208128] pc : __do_softirq+0xb0/0x368<br /> [ 28.212055] lr : __do_softirq+0x70/0x368<br /> [ 28.215972] sp : ffffff8035ebca00<br /> [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780<br /> [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0<br /> [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b<br /> [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff<br /> [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000<br /> [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2<br /> [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250<br /> [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434<br /> [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198<br /> [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40<br /> [ 28.290611] Call trace:<br /> [ 28.293052] __do_softirq+0xb0/0x368<br /> [ 28.296625] __irq_exit_rcu+0xe0/0x100<br /> [ 28.300374] irq_exit+0x14/0x20<br /> [ 28.303513] handle_domain_irq+0x68/0x90<br /> [ 28.307440] gic_handle_irq+0x78/0xb0<br /> [ 28.311098] call_on_irq_stack+0x20/0x38<br /> [ 28.315019] do_interrupt_handler+0x54/0x5c<br /> [ 28.319199] el1_interrupt+0x2c/0x4c<br /> [ 28.322777] el1h_64_irq_handler+0x14/0x20<br /> [ 28.326872] el1h_64_irq+0x74/0x78<br /> [ 28.330269] __setup_irq+0x454/0x780<br /> [ 28.333841] request_threaded_irq+0xd0/0x1b4<br /> [ 28.338107] devm_request_threaded_irq+0x84/0x100<br /> [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0<br /> [ 28.346990] platform_probe+0x6c/0xc4<br /> [ 28.350653] really_probe+0xcc/0x45c<br /> [ 28.354227] __driver_probe_device+0x8c/0x160<br /> [ 28.358578] driver_probe_device+0x44/0xe0<br /> [ 28.362670] __driver_attach+0x124/0x1d0<br /> [ 28.366589] bus_for_each_dev+0x7c/0xe0<br /> [ 28.370426] driver_attach+0x28/0x30<br /> [ 28.373997] bus_add_driver+0x124/0x240<br /> [ 28.377830] driver_register+0x7c/0x124<br /> [ 28.381662] __platform_driver_register+0x2c/0x34<br /> [ 28.386362] npcm_i2c_init+0x3c/0x5c<br /> [ 28.389937] do_one_initcall+0x74/0x230<br /> [ 28.393768] kernel_init_freeable+0x24c/0x2b4<br /> [ 28.398126] kernel_init+0x28/0x130<br /> [ 28.401614] ret_from_fork+0x10/0x20<br /> [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks<br /> [ 28.411011] SMP: stopping secondary CPUs<br /> [ 28.414933] Kernel Offset: disabled<br /> [ 28.418412] CPU features: 0x00000000,00000802<br /> [ 28.427644] Rebooting in 20 seconds..

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-dma: Add shadow buffering for deferred I/O<br /> <br /> DMA areas are not necessarily backed by struct page, so we cannot<br /> rely on it for deferred I/O. Allocate a shadow buffer for drivers<br /> that require deferred I/O and use it as framebuffer memory.<br /> <br /> Fixes driver errors about being "Unable to handle kernel NULL pointer<br /> dereference at virtual address" or "Unable to handle kernel paging<br /> request at virtual address".<br /> <br /> The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial<br /> allocation, which creates the DMA-backed buffer object, and a tail<br /> that sets up the fbdev data structures. There is a tail function for<br /> direct memory mappings and a tail function for deferred I/O with<br /> the shadow buffer.<br /> <br /> It is no longer possible to use deferred I/O without shadow buffer.<br /> It can be re-added if there exists a reliably test for usable struct<br /> page in the allocated DMA-backed buffer object.

IBM UrbanCode Deploy (UCD) 7.0 through 7.0.5.25, 7.1 through 7.1.2.21, 7.2 through 7.2.3.14, and 7.3 through 7.3.2.0 / IBM DevOps Deploy 8.0 through 8.0.1.4 and 8.1 through 8.1 <br /> <br /> is vulnerable to HTML injection. This vulnerability may allow a user to embed arbitrary HTML tags in the Web UI potentially leading to sensitive information disclosure.