Vulnerabilities

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.

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.

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: Don&amp;#39;t map the entire mokvar table to determine its size<br /> <br /> Currently, when validating the mokvar table, we (re)map the entire table<br /> on each iteration of the loop, adding space as we discover new entries.<br /> If the table grows over a certain size, this fails due to limitations of<br /> early_memmap(), and we get a failure and traceback:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220<br /> ...<br /> Call Trace:<br /> <br /> ? __early_ioremap+0xef/0x220<br /> ? __warn.cold+0x93/0xfa<br /> ? __early_ioremap+0xef/0x220<br /> ? report_bug+0xff/0x140<br /> ? early_fixup_exception+0x5d/0xb0<br /> ? early_idt_handler_common+0x2f/0x3a<br /> ? __early_ioremap+0xef/0x220<br /> ? efi_mokvar_table_init+0xce/0x1d0<br /> ? setup_arch+0x864/0xc10<br /> ? start_kernel+0x6b/0xa10<br /> ? x86_64_start_reservations+0x24/0x30<br /> ? x86_64_start_kernel+0xed/0xf0<br /> ? common_startup_64+0x13e/0x141<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.<br /> <br /> Mapping the entire structure isn&amp;#39;t actually necessary, as we don&amp;#39;t ever<br /> need more than one entry header mapped at once.<br /> <br /> Changes efi_mokvar_table_init() to only map each entry header, not the<br /> entire table, when determining the table size. Since we&amp;#39;re not mapping<br /> any data past the variable name, it also changes the code to enforce<br /> that each variable name is NUL terminated, rather than attempting to<br /> verify it in place.

IBM UrbanCode Deploy (UCD) 7.1 through 7.1.2.22, 7.2 through 7.2.3.15, and 7.3 through 7.3.2.10 / IBM DevOps Deploy 8.0 through 8.0.1.5 and 8.1 through 8.1.0.1 could allow unauthorized access to other services or potential exposure of sensitive data due to missing authentication in its Agent Relay service.

Server-Side Request Forgery (SSRF) vulnerability in Apache Kylin. Through a kylin server, an attacker may forge a request to invoke "/kylin/api/xxx/diag" api on another internal host and possibly get leaked information. There are two preconditions: 1) The attacker has got admin access to a kylin server; 2) Another internal host has the "/kylin/api/xxx/diag" api<br /> <br /> endpoint open for service.<br /> <br /> <br /> This issue affects Apache Kylin: from 5.0.0 <br /> through <br /> <br /> 5.0.1.<br /> <br /> Users are recommended to upgrade to version 5.0.2, which fixes the issue.