Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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/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 /> sched/core: Prevent rescheduling when interrupts are disabled<br /> <br /> David reported a warning observed while loop testing kexec jump:<br /> <br /> Interrupts enabled after irqrouter_resume+0x0/0x50<br /> WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220<br /> kernel_kexec+0xf6/0x180<br /> __do_sys_reboot+0x206/0x250<br /> do_syscall_64+0x95/0x180<br /> <br /> The corresponding interrupt flag trace:<br /> <br /> hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90<br /> hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90<br /> <br /> That means __up_console_sem() was invoked with interrupts enabled. Further<br /> instrumentation revealed that in the interrupt disabled section of kexec<br /> jump one of the syscore_suspend() callbacks woke up a task, which set the<br /> NEED_RESCHED flag. A later callback in the resume path invoked<br /> cond_resched() which in turn led to the invocation of the scheduler:<br /> <br /> __cond_resched+0x21/0x60<br /> down_timeout+0x18/0x60<br /> acpi_os_wait_semaphore+0x4c/0x80<br /> acpi_ut_acquire_mutex+0x3d/0x100<br /> acpi_ns_get_node+0x27/0x60<br /> acpi_ns_evaluate+0x1cb/0x2d0<br /> acpi_rs_set_srs_method_data+0x156/0x190<br /> acpi_pci_link_set+0x11c/0x290<br /> irqrouter_resume+0x54/0x60<br /> syscore_resume+0x6a/0x200<br /> kernel_kexec+0x145/0x1c0<br /> __do_sys_reboot+0xeb/0x240<br /> do_syscall_64+0x95/0x180<br /> <br /> This is a long standing problem, which probably got more visible with<br /> the recent printk changes. Something does a task wakeup and the<br /> scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and<br /> invokes schedule() from a completely bogus context. The scheduler<br /> enables interrupts after context switching, which causes the above<br /> warning at the end.<br /> <br /> Quite some of the code paths in syscore_suspend()/resume() can result in<br /> triggering a wakeup with the exactly same consequences. They might not<br /> have done so yet, but as they share a lot of code with normal operations<br /> it&amp;#39;s just a question of time.<br /> <br /> The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling<br /> models. Full preemption is not affected as cond_resched() is disabled and<br /> the preemption check preemptible() takes the interrupt disabled flag into<br /> account.<br /> <br /> Cure the problem by adding a corresponding check into cond_resched().

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 could allow unauthorized access to other services or potential exposure of sensitive data due to missing authentication in its Agent Relay service.

IBM UrbanCode Deploy (UCD) 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 /> stores potentially sensitive authentication token information in log files that could be read by a local user.