Vulnerabilities

Discourse Calendar adds the ability to create a dynamic calendar in the first post of a topic on the open-source discussion platform Discourse. Prior to version 0.4, event invitees created in topics in private categories or PMs (private messages) can be retrieved by anyone, even if they're not logged in. This problem is resolved in version 0.4 of the discourse-calendar plugin. While no known workaround is available, putting the site behind `login_required` will disallow this endpoint to be used by anonymous users, but logged in users can still get the list of invitees in the private topics.

SKINsoft S-Museum 7.02.3 allows Unrestricted File Upload via the Add Media function. Unlike in CVE-2024-25801, the attack payload is the file content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS<br /> <br /> For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off<br /> for validation. However, variable offset ptr alu is not prohibited<br /> for this ptr kind. So the variable offset is not checked.<br /> <br /> The following prog is accepted:<br /> <br /> func#0 @0<br /> 0: R1=ctx() R10=fp0<br /> 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx()<br /> 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys()<br /> 2: (b7) r8 = 1024 ; R8_w=1024<br /> 3: (37) r8 /= 1 ; R8_w=scalar()<br /> 4: (57) r8 &amp;= 1024 ; R8_w=scalar(smin=smin32=0,<br /> smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))<br /> 5: (0f) r7 += r8<br /> mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1<br /> mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &amp;= 1024<br /> mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1<br /> mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024<br /> 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off<br /> =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,<br /> var_off=(0x0; 0x400))<br /> 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar()<br /> 7: (95) exit<br /> <br /> This prog loads flow_keys to r7, and adds the variable offset r8<br /> to r7, and finally causes out-of-bounds access:<br /> <br /> BUG: unable to handle page fault for address: ffffc90014c80038<br /> [...]<br /> Call Trace:<br /> <br /> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]<br /> __bpf_prog_run include/linux/filter.h:651 [inline]<br /> bpf_prog_run include/linux/filter.h:658 [inline]<br /> bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]<br /> bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991<br /> bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359<br /> bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]<br /> __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475<br /> __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]<br /> __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Fix this by rejecting ptr alu with variable offset on flow_keys.<br /> Applying the patch rejects the program with "R7 pointer arithmetic<br /> on flow_keys prohibited".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix inconsistent per-file compression format<br /> <br /> EROFS can select compression algorithms on a per-file basis, and each<br /> per-file compression algorithm needs to be marked in the on-disk<br /> superblock for initialization.<br /> <br /> However, syzkaller can generate inconsistent crafted images that use<br /> an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA<br /> algorithmtype even it&amp;#39;s not set in `sbi-&gt;available_compr_algs`. This<br /> can lead to an unexpected "BUG: kernel NULL pointer dereference" if<br /> the corresponding decompressor isn&amp;#39;t built-in.<br /> <br /> Fix this by checking against `sbi-&gt;available_compr_algs` for each<br /> m_algorithmformat request. Incorrect !erofs_sb_has_compr_cfgs preset<br /> bitmap is now fixed together since it was harmless previously.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix re-attachment branch in bpf_tracing_prog_attach<br /> <br /> The following case can cause a crash due to missing attach_btf:<br /> <br /> 1) load rawtp program<br /> 2) load fentry program with rawtp as target_fd<br /> 3) create tracing link for fentry program with target_fd = 0<br /> 4) repeat 3<br /> <br /> In the end we have:<br /> <br /> - prog-&gt;aux-&gt;dst_trampoline == NULL<br /> - tgt_prog == NULL (because we did not provide target_fd to link_create)<br /> - prog-&gt;aux-&gt;attach_btf == NULL (the program was loaded with attach_prog_fd=X)<br /> - the program was loaded for tgt_prog but we have no way to find out which one<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> Call Trace:<br /> <br /> ? __die+0x20/0x70<br /> ? page_fault_oops+0x15b/0x430<br /> ? fixup_exception+0x22/0x330<br /> ? exc_page_fault+0x6f/0x170<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? bpf_tracing_prog_attach+0x279/0x560<br /> ? btf_obj_id+0x5/0x10<br /> bpf_tracing_prog_attach+0x439/0x560<br /> __sys_bpf+0x1cf4/0x2de0<br /> __x64_sys_bpf+0x1c/0x30<br /> do_syscall_64+0x41/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Return -EINVAL in this situation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix UAF issue in ksmbd_tcp_new_connection()<br /> <br /> The race is between the handling of a new TCP connection and<br /> its disconnection. It leads to UAF on `struct tcp_transport` in<br /> ksmbd_tcp_new_connection() function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: avoid crash when parsed profile name is empty<br /> <br /> When processing a packed profile in unpack_profile() described like<br /> <br /> "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"<br /> <br /> a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then<br /> passed to aa_splitn_fqname().<br /> <br /> aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.<br /> Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later<br /> aa_alloc_profile() crashes as the new profile name is NULL now.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> RIP: 0010:strlen+0x1e/0xa0<br /> Call Trace:<br /> <br /> ? strlen+0x1e/0xa0<br /> aa_policy_init+0x1bb/0x230<br /> aa_alloc_profile+0xb1/0x480<br /> unpack_profile+0x3bc/0x4960<br /> aa_unpack+0x309/0x15e0<br /> aa_replace_profiles+0x213/0x33c0<br /> policy_update+0x261/0x370<br /> profile_replace+0x20e/0x2a0<br /> vfs_write+0x2af/0xe00<br /> ksys_write+0x126/0x250<br /> do_syscall_64+0x46/0xf0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:strlen+0x1e/0xa0<br /> <br /> It seems such behaviour of aa_splitn_fqname() is expected and checked in<br /> other places where it is called (e.g. aa_remove_profiles). Well, there<br /> is an explicit comment "a ns name without a following profile is allowed"<br /> inside.<br /> <br /> AFAICS, nothing can prevent unpacked "name" to be in form like<br /> ":samba-dcerpcd" - it is passed from userspace.<br /> <br /> Deny the whole profile set replacement in such case and inform user with<br /> EPROTO and an explaining message.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid dirent corruption<br /> <br /> As Al reported in link[1]:<br /> <br /> f2fs_rename()<br /> ...<br /> if (old_dir != new_dir &amp;&amp; !whiteout)<br /> f2fs_set_link(old_inode, old_dir_entry,<br /> old_dir_page, new_dir);<br /> else<br /> f2fs_put_page(old_dir_page, 0);<br /> <br /> You want correct inumber in the ".." link. And cross-directory<br /> rename does move the source to new parent, even if you&amp;#39;d been asked<br /> to leave a whiteout in the old place.<br /> <br /> [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/<br /> <br /> With below testcase, it may cause dirent corruption, due to it missed<br /> to call f2fs_set_link() to update ".." link to new directory.<br /> - mkdir -p dir/foo<br /> - renameat2 -w dir/foo bar<br /> <br /> [ASSERT] (__chk_dots_dentries:1421) --&gt; Bad inode number[0x4] for &amp;#39;..&amp;#39;, parent parent ino is [0x3]<br /> [FSCK] other corrupted bugs [Fail]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pvrusb2: fix use after free on context disconnection<br /> <br /> Upon module load, a kthread is created targeting the<br /> pvr2_context_thread_func function, which may call pvr2_context_destroy<br /> and thus call kfree() on the context object. However, that might happen<br /> before the usb hub_event handler is able to notify the driver. This<br /> patch adds a sanity check before the invalid read reported by syzbot,<br /> within the context disconnection call stack.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a race condition between btf_put() and map_free()<br /> <br /> When running `./test_progs -j` in my local vm with latest kernel,<br /> I once hit a kasan error like below:<br /> <br /> [ 1887.184724] BUG: KASAN: slab-use-after-free in bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.185599] Read of size 4 at addr ffff888106806910 by task kworker/u12:2/2830<br /> [ 1887.186498]<br /> [ 1887.186712] CPU: 3 PID: 2830 Comm: kworker/u12:2 Tainted: G OEL 6.7.0-rc3-00699-g90679706d486-dirty #494<br /> [ 1887.188034] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 1887.189618] Workqueue: events_unbound bpf_map_free_deferred<br /> [ 1887.190341] Call Trace:<br /> [ 1887.190666] <br /> [ 1887.190949] dump_stack_lvl+0xac/0xe0<br /> [ 1887.191423] ? nf_tcp_handle_invalid+0x1b0/0x1b0<br /> [ 1887.192019] ? panic+0x3c0/0x3c0<br /> [ 1887.192449] print_report+0x14f/0x720<br /> [ 1887.192930] ? preempt_count_sub+0x1c/0xd0<br /> [ 1887.193459] ? __virt_addr_valid+0xac/0x120<br /> [ 1887.194004] ? bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.194572] kasan_report+0xc3/0x100<br /> [ 1887.195085] ? bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.195668] bpf_rb_root_free+0x1f8/0x2b0<br /> [ 1887.196183] ? __bpf_obj_drop_impl+0xb0/0xb0<br /> [ 1887.196736] ? preempt_count_sub+0x1c/0xd0<br /> [ 1887.197270] ? preempt_count_sub+0x1c/0xd0<br /> [ 1887.197802] ? _raw_spin_unlock+0x1f/0x40<br /> [ 1887.198319] bpf_obj_free_fields+0x1d4/0x260<br /> [ 1887.198883] array_map_free+0x1a3/0x260<br /> [ 1887.199380] bpf_map_free_deferred+0x7b/0xe0<br /> [ 1887.199943] process_scheduled_works+0x3a2/0x6c0<br /> [ 1887.200549] worker_thread+0x633/0x890<br /> [ 1887.201047] ? __kthread_parkme+0xd7/0xf0<br /> [ 1887.201574] ? kthread+0x102/0x1d0<br /> [ 1887.202020] kthread+0x1ab/0x1d0<br /> [ 1887.202447] ? pr_cont_work+0x270/0x270<br /> [ 1887.202954] ? kthread_blkcg+0x50/0x50<br /> [ 1887.203444] ret_from_fork+0x34/0x50<br /> [ 1887.203914] ? kthread_blkcg+0x50/0x50<br /> [ 1887.204397] ret_from_fork_asm+0x11/0x20<br /> [ 1887.204913] <br /> [ 1887.204913] <br /> [ 1887.205209]<br /> [ 1887.205416] Allocated by task 2197:<br /> [ 1887.205881] kasan_set_track+0x3f/0x60<br /> [ 1887.206366] __kasan_kmalloc+0x6e/0x80<br /> [ 1887.206856] __kmalloc+0xac/0x1a0<br /> [ 1887.207293] btf_parse_fields+0xa15/0x1480<br /> [ 1887.207836] btf_parse_struct_metas+0x566/0x670<br /> [ 1887.208387] btf_new_fd+0x294/0x4d0<br /> [ 1887.208851] __sys_bpf+0x4ba/0x600<br /> [ 1887.209292] __x64_sys_bpf+0x41/0x50<br /> [ 1887.209762] do_syscall_64+0x4c/0xf0<br /> [ 1887.210222] entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> [ 1887.210868]<br /> [ 1887.211074] Freed by task 36:<br /> [ 1887.211460] kasan_set_track+0x3f/0x60<br /> [ 1887.211951] kasan_save_free_info+0x28/0x40<br /> [ 1887.212485] ____kasan_slab_free+0x101/0x180<br /> [ 1887.213027] __kmem_cache_free+0xe4/0x210<br /> [ 1887.213514] btf_free+0x5b/0x130<br /> [ 1887.213918] rcu_core+0x638/0xcc0<br /> [ 1887.214347] __do_softirq+0x114/0x37e<br /> <br /> The error happens at bpf_rb_root_free+0x1f8/0x2b0:<br /> <br /> 00000000000034c0 :<br /> ; {<br /> 34c0: f3 0f 1e fa endbr64<br /> 34c4: e8 00 00 00 00 callq 0x34c9 <br /> 34c9: 55 pushq %rbp<br /> 34ca: 48 89 e5 movq %rsp, %rbp<br /> ...<br /> ; if (rec &amp;&amp; rec-&gt;refcount_off &gt;= 0 &amp;&amp;<br /> 36aa: 4d 85 ed testq %r13, %r13<br /> 36ad: 74 a9 je 0x3658 <br /> 36af: 49 8d 7d 10 leaq 0x10(%r13), %rdi<br /> 36b3: e8 00 00 00 00 callq 0x36b8 <br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Defer the free of inner map when necessary<br /> <br /> When updating or deleting an inner map in map array or map htab, the map<br /> may still be accessed by non-sleepable program or sleepable program.<br /> However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map<br /> directly through bpf_map_put(), if the ref-counter is the last one<br /> (which is true for most cases), the inner map will be freed by<br /> ops-&gt;map_free() in a kworker. But for now, most .map_free() callbacks<br /> don&amp;#39;t use synchronize_rcu() or its variants to wait for the elapse of a<br /> RCU grace period, so after the invocation of ops-&gt;map_free completes,<br /> the bpf program which is accessing the inner map may incur<br /> use-after-free problem.<br /> <br /> Fix the free of inner map by invoking bpf_map_free_deferred() after both<br /> one RCU grace period and one tasks trace RCU grace period if the inner<br /> map has been removed from the outer map before. The deferment is<br /> accomplished by using call_rcu() or call_rcu_tasks_trace() when<br /> releasing the last ref-counter of bpf map. The newly-added rcu_head<br /> field in bpf_map shares the same storage space with work field to<br /> reduce the size of bpf_map.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump<br /> <br /> Syzkaller has reported a NULL pointer dereference when accessing<br /> rgd-&gt;rd_rgl in gfs2_rgrp_dump(). This can happen when creating<br /> rgd-&gt;rd_gl fails in read_rindex_entry(). Add a NULL pointer check in<br /> gfs2_rgrp_dump() to prevent that.