Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix underflow in second superblock position calculations<br /> <br /> Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second<br /> superblock, underflows when the argument device size is less than 4096<br /> bytes. Therefore, when using this macro, it is necessary to check in<br /> advance that the device size is not less than a lower limit, or at least<br /> that underflow does not occur.<br /> <br /> The current nilfs2 implementation lacks this check, causing out-of-bound<br /> block access when mounting devices smaller than 4096 bytes:<br /> <br /> I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0<br /> phys_seg 1 prio class 2<br /> NILFS (loop0): unable to read secondary superblock (blocksize = 1024)<br /> <br /> In addition, when trying to resize the filesystem to a size below 4096<br /> bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number<br /> of segments to nilfs_sufile_resize(), corrupting parameters such as the<br /> number of segments in superblocks. This causes excessive loop iterations<br /> in nilfs_sufile_resize() during a subsequent resize ioctl, causing<br /> semaphore ns_segctor_sem to block for a long time and hang the writer<br /> thread:<br /> <br /> INFO: task segctord:5067 blocked for more than 143 seconds.<br /> Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:segctord state:D stack:23456 pid:5067 ppid:2<br /> flags:0x00004000<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5293 [inline]<br /> __schedule+0x1409/0x43f0 kernel/sched/core.c:6606<br /> schedule+0xc3/0x190 kernel/sched/core.c:6682<br /> rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190<br /> nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357<br /> nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]<br /> nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570<br /> kthread+0x270/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308<br /> <br /> ...<br /> Call Trace:<br /> <br /> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515<br /> __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]<br /> nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61<br /> nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121<br /> nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176<br /> nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251<br /> nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]<br /> nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]<br /> nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777<br /> nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422<br /> nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]<br /> nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301<br /> ...<br /> <br /> This fixes these issues by inserting appropriate minimum device size<br /> checks or anti-underflow checks, depending on where the macro is used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sim: fix a memory leak<br /> <br /> Fix an inverted logic bug in gpio_sim_remove_hogs() that leads to GPIO<br /> hog structures never being freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: Fix use-after-free in ep_remove_wait_queue()<br /> <br /> If a non-root cgroup gets removed when there is a thread that registered<br /> trigger and is polling on a pressure file within the cgroup, the polling<br /> waitqueue gets freed in the following path:<br /> <br /> do_rmdir<br /> cgroup_rmdir<br /> kernfs_drain_open_files<br /> cgroup_file_release<br /> cgroup_pressure_release<br /> psi_trigger_destroy<br /> <br /> However, the polling thread still has a reference to the pressure file and<br /> will access the freed waitqueue when the file is closed or upon exit:<br /> <br /> fput<br /> ep_eventpoll_release<br /> ep_free<br /> ep_remove_wait_queue<br /> remove_wait_queue<br /> <br /> This results in use-after-free as pasted below.<br /> <br /> The fundamental problem here is that cgroup_file_release() (and<br /> consequently waitqueue&amp;#39;s lifetime) is not tied to the file&amp;#39;s real lifetime.<br /> Using wake_up_pollfree() here might be less than ideal, but it is in line<br /> with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")<br /> since the waitqueue&amp;#39;s lifetime is not tied to file&amp;#39;s one and can be<br /> considered as another special case. While this would be fixable by somehow<br /> making cgroup_file_release() be tied to the fput(), it would require<br /> sizable refactoring at cgroups or higher layer which might be more<br /> justifiable if we identify more cases like this.<br /> <br /> BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0<br /> Write of size 4 at addr ffff88810e625328 by task a.out/4404<br /> <br /> CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38<br /> Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x73/0xa0<br /> print_report+0x16c/0x4e0<br /> kasan_report+0xc3/0xf0<br /> kasan_check_range+0x2d2/0x310<br /> _raw_spin_lock_irqsave+0x60/0xc0<br /> remove_wait_queue+0x1a/0xa0<br /> ep_free+0x12c/0x170<br /> ep_eventpoll_release+0x26/0x30<br /> __fput+0x202/0x400<br /> task_work_run+0x11d/0x170<br /> do_exit+0x495/0x1130<br /> do_group_exit+0x100/0x100<br /> get_signal+0xd67/0xde0<br /> arch_do_signal_or_restart+0x2a/0x2b0<br /> exit_to_user_mode_prepare+0x94/0x100<br /> syscall_exit_to_user_mode+0x20/0x40<br /> do_syscall_64+0x52/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> <br /> Allocated by task 4404:<br /> <br /> kasan_set_track+0x3d/0x60<br /> __kasan_kmalloc+0x85/0x90<br /> psi_trigger_create+0x113/0x3e0<br /> pressure_write+0x146/0x2e0<br /> cgroup_file_write+0x11c/0x250<br /> kernfs_fop_write_iter+0x186/0x220<br /> vfs_write+0x3d8/0x5c0<br /> ksys_write+0x90/0x110<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Freed by task 4407:<br /> <br /> kasan_set_track+0x3d/0x60<br /> kasan_save_free_info+0x27/0x40<br /> ____kasan_slab_free+0x11d/0x170<br /> slab_free_freelist_hook+0x87/0x150<br /> __kmem_cache_free+0xcb/0x180<br /> psi_trigger_destroy+0x2e8/0x310<br /> cgroup_file_release+0x4f/0xb0<br /> kernfs_drain_open_files+0x165/0x1f0<br /> kernfs_drain+0x162/0x1a0<br /> __kernfs_remove+0x1fb/0x310<br /> kernfs_remove_by_name_ns+0x95/0xe0<br /> cgroup_addrm_files+0x67f/0x700<br /> cgroup_destroy_locked+0x283/0x3c0<br /> cgroup_rmdir+0x29/0x100<br /> kernfs_iop_rmdir+0xd1/0x140<br /> vfs_rmdir+0xfe/0x240<br /> do_rmdir+0x13d/0x280<br /> __x64_sys_rmdir+0x2c/0x30<br /> do_syscall_64+0x43/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

A Stored Cross-site Scripting (XSS) vulnerability in the "Import of Users and login name of user" feature in ILIAS 7 before 7.30 and ILIAS 8 before 8.11 allows remote authenticated attackers with administrative privileges to inject arbitrary web script or HTML via XML file upload.

A Stored Cross-site Scripting (XSS) vulnerability in ILIAS 7 before 7.30 and ILIAS 8 before 8.11 allows remote authenticated attackers with tutor privileges to inject arbitrary web script or HTML via XML file upload.

ILIAS 7 before 7.30 and ILIAS 8 before 8.11 as well as ILIAS 9.0 allow remote authenticated attackers with administrative privileges to execute operating system commands via file uploads with dangerous types.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, s390: Fix potential memory leak about jit_data<br /> <br /> Make sure to free jit_data through kfree() in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi: Fix iscsi_task use after free<br /> <br /> Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")<br /> added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but<br /> then also changed the handling of the case where we detect an already<br /> completed task where we now end up doing a goto to the common put/cleanup<br /> code. This results in a iscsi_task use after free, because the common<br /> cleanup code will do a put on the iscsi_task.<br /> <br /> This reverts the goto and moves the iscsi_get_conn() to after we&amp;#39;ve checked<br /> if the iscsi_task is valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: fix program check interrupt emergency stack path<br /> <br /> Emergency stack path was jumping into a 3: label inside the<br /> __GEN_COMMON_BODY macro for the normal path after it had finished,<br /> rather than jumping over it. By a small miracle this is the correct<br /> place to build up a new interrupt frame with the existing stack<br /> pointer, so things basically worked okay with an added weird looking<br /> 700 trap frame on top (which had the wrong -&gt;nip so it didn&amp;#39;t decode<br /> bug messages either).<br /> <br /> Fix this by avoiding using numeric labels when jumping over non-trivial<br /> macros.<br /> <br /> Before:<br /> <br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV<br /> Modules linked in:<br /> CPU: 0 PID: 88 Comm: sh Not tainted 5.15.0-rc2-00034-ge057cdade6e5 #2637<br /> NIP: 7265677368657265 LR: c00000000006c0c8 CTR: c0000000000097f0<br /> REGS: c0000000fffb3a50 TRAP: 0700 Not tainted<br /> MSR: 9000000000021031 CR: 00000700 XER: 20040000<br /> CFAR: c0000000000098b0 IRQMASK: 0<br /> GPR00: c00000000006c964 c0000000fffb3cf0 c000000001513800 0000000000000000<br /> GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299<br /> GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8<br /> GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001<br /> GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8<br /> GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158<br /> GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300<br /> GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80<br /> NIP [7265677368657265] 0x7265677368657265<br /> LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10<br /> Call Trace:<br /> [c0000000fffb3cf0] [c00000000000bdac] soft_nmi_common+0x13c/0x1d0 (unreliable)<br /> --- interrupt: 700 at decrementer_common_virt+0xb8/0x230<br /> NIP: c0000000000098b8 LR: c00000000006c0c8 CTR: c0000000000097f0<br /> REGS: c0000000fffb3d60 TRAP: 0700 Not tainted<br /> MSR: 9000000000021031 CR: 22424282 XER: 20040000<br /> CFAR: c0000000000098b0 IRQMASK: 0<br /> GPR00: c00000000006c964 0000000000002400 c000000001513800 0000000000000000<br /> GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299<br /> GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8<br /> GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001<br /> GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8<br /> GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158<br /> GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300<br /> GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80<br /> NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230<br /> LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10<br /> --- interrupt: 700<br /> Instruction dump:<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX<br /> ---[ end trace 6d28218e0cc3c949 ]---<br /> <br /> After:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at arch/powerpc/kernel/exceptions-64s.S:491!<br /> Oops: Exception in kernel mode, sig: 5 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV<br /> Modules linked in:<br /> CPU: 0 PID: 88 Comm: login Not tainted 5.15.0-rc2-00034-ge057cdade6e5-dirty #2638<br /> NIP: c0000000000098b8 LR: c00000000006bf04 CTR: c0000000000097f0<br /> REGS: c0000000fffb3d60 TRAP: 0700 Not tainted<br /> MSR: 9000000000021031 CR: 24482227 XER: 00040000<br /> CFAR: c0000000000098b0 IRQMASK: 0<br /> GPR00: c00000000006bf04 0000000000002400 c000000001513800 c000000001271868<br /> GPR04: 00000000100f0d29 0000000042000000 0000000000000007 0000000000000009<br /> GPR08: 00000000100f0d29 0000000024482227 0000000000002710 c000000000181b3c<br /> GPR12: 9000000000009033 c0000000016b0000 00000000100f0d29 c000000005b22f00<br /> GPR16: 00000000ffff0000 0000000000000001 0000000000000009 00000000100eed90<br /> GPR20: 00000000100eed90 00000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64s: Fix unrecoverable MCE calling async handler from NMI<br /> <br /> The machine check handler is not considered NMI on 64s. The early<br /> handler is the true NMI handler, and then it schedules the<br /> machine_check_exception handler to run when interrupts are enabled.<br /> <br /> This works fine except the case of an unrecoverable MCE, where the true<br /> NMI is taken when MSR[RI] is clear, it can not recover, so it calls<br /> machine_check_exception directly so something might be done about it.<br /> <br /> Calling an async handler from NMI context can result in irq state and<br /> other things getting corrupted. This can also trigger the BUG at<br /> arch/powerpc/include/asm/interrupt.h:168<br /> BUG_ON(!arch_irq_disabled_regs(regs) &amp;&amp; !(regs-&gt;msr &amp; MSR_EE));<br /> <br /> Fix this by making an _async version of the handler which is called<br /> in the normal case, and a NMI version that is called for unrecoverable<br /> interrupts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n<br /> <br /> Commit<br /> <br /> 3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks")<br /> <br /> added a warning if AC is set when in the kernel.<br /> <br /> Commit<br /> <br /> 662a0221893a3d ("x86/entry: Fix AC assertion")<br /> <br /> changed the warning to only fire if the CPU supports SMAP.<br /> <br /> However, the warning can still trigger on a machine that supports SMAP<br /> but where it&amp;#39;s disabled in the kernel config and when running the<br /> syscall_nt selftest, for example:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode<br /> CPU: 0 PID: 49 Comm: init Tainted: G T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014<br /> RIP: 0010:irqentry_enter_from_user_mode<br /> ...<br /> Call Trace:<br /> ? irqentry_enter<br /> ? exc_general_protection<br /> ? asm_exc_general_protection<br /> ? asm_exc_general_protectio<br /> <br /> IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but<br /> even this would not be enough in case SMAP is disabled at boot time with<br /> the "nosmap" parameter.<br /> <br /> To be consistent with "nosmap" behaviour, clear X86_FEATURE_SMAP when<br /> !CONFIG_X86_SMAP.<br /> <br /> Found using entry-fuzz + satrandconfig.<br /> <br /> [ bp: Massage commit message. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix gart.bo pin_count leak<br /> <br /> gmc_v{9,10}_0_gart_disable() isn&amp;#39;t called matched with<br /> correspoding gart_enbale function in SRIOV case. This will<br /> lead to gart.bo pin_count leak on driver unload.