Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix data corruption by fallocate<br /> <br /> When fallocate punches holes out of inode size, if original isize is in<br /> the middle of last cluster, then the part from isize to the end of the<br /> cluster will be zeroed with buffer write, at that time isize is not yet<br /> updated to match the new size, if writeback is kicked in, it will invoke<br /> ocfs2_writepage()-&gt;block_write_full_page() where the pages out of inode<br /> size will be dropped. That will cause file corruption. Fix this by<br /> zero out eof blocks when extending the inode size.<br /> <br /> Running the following command with qemu-image 4.2.1 can get a corrupted<br /> coverted image file easily.<br /> <br /> qemu-img convert -p -t none -T none -f qcow2 $qcow_image \<br /> -O qcow2 -o compat=1.1 $qcow_image.conv<br /> <br /> The usage of fallocate in qemu is like this, it first punches holes out<br /> of inode size, then extend the inode size.<br /> <br /> fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0<br /> fallocate(11, 0, 2276196352, 65536) = 0<br /> <br /> v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html<br /> v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix memory leak in ext4_mb_init_backend on error path.<br /> <br /> Fix a memory leak discovered by syzbot when a file system is corrupted<br /> with an illegally large s_log_groups_per_flex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed<br /> <br /> We got follow bug_on when run fsstress with injecting IO fault:<br /> [130747.323114] kernel BUG at fs/ext4/extents_status.c:762!<br /> [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP<br /> ......<br /> [130747.334329] Call trace:<br /> [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4]<br /> [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4]<br /> [130747.335368] ext4_find_extent+0x300/0x330 [ext4]<br /> [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4]<br /> [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4]<br /> [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4]<br /> [130747.336995] ext4_readpage+0x54/0x100 [ext4]<br /> [130747.337359] generic_file_buffered_read+0x410/0xae8<br /> [130747.337767] generic_file_read_iter+0x114/0x190<br /> [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4]<br /> [130747.338556] __vfs_read+0x11c/0x188<br /> [130747.338851] vfs_read+0x94/0x150<br /> [130747.339110] ksys_read+0x74/0xf0<br /> <br /> This patch&amp;#39;s modification is according to Jan Kara&amp;#39;s suggestion in:<br /> https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/<br /> "I see. Now I understand your patch. Honestly, seeing how fragile is trying<br /> to fix extent tree after split has failed in the middle, I would probably<br /> go even further and make sure we fix the tree properly in case of ENOSPC<br /> and EDQUOT (those are easily user triggerable). Anything else indicates a<br /> HW problem or fs corruption so I&amp;#39;d rather leave the extent tree as is and<br /> don&amp;#39;t try to fix it (which also means we will not create overlapping<br /> extents)."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pid: take a reference when initializing `cad_pid`<br /> <br /> During boot, kernel_init_freeable() initializes `cad_pid` to the init<br /> task&amp;#39;s struct pid. Later on, we may change `cad_pid` via a sysctl, and<br /> when this happens proc_do_cad_pid() will increment the refcount on the<br /> new pid via get_pid(), and will decrement the refcount on the old pid<br /> via put_pid(). As we never called get_pid() when we initialized<br /> `cad_pid`, we decrement a reference we never incremented, can therefore<br /> free the init task&amp;#39;s struct pid early. As there can be dangling<br /> references to the struct pid, we can later encounter a use-after-free<br /> (e.g. when delivering signals).<br /> <br /> This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to<br /> have been around since the conversion of `cad_pid` to struct pid in<br /> commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the<br /> pre-KASAN stone age of v2.6.19.<br /> <br /> Fix this by getting a reference to the init task&amp;#39;s struct pid when we<br /> assign it to `cad_pid`.<br /> <br /> Full KASAN splat below.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline]<br /> BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509<br /> Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273<br /> <br /> CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> ns_of_pid include/linux/pid.h:153 [inline]<br /> task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509<br /> do_notify_parent+0x308/0xe60 kernel/signal.c:1950<br /> exit_notify kernel/exit.c:682 [inline]<br /> do_exit+0x2334/0x2bd0 kernel/exit.c:845<br /> do_group_exit+0x108/0x2c8 kernel/exit.c:922<br /> get_signal+0x4e4/0x2a88 kernel/signal.c:2781<br /> do_signal arch/arm64/kernel/signal.c:882 [inline]<br /> do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936<br /> work_pending+0xc/0x2dc<br /> <br /> Allocated by task 0:<br /> slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516<br /> slab_alloc_node mm/slub.c:2907 [inline]<br /> slab_alloc mm/slub.c:2915 [inline]<br /> kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920<br /> alloc_pid+0xdc/0xc00 kernel/pid.c:180<br /> copy_process+0x2794/0x5e18 kernel/fork.c:2129<br /> kernel_clone+0x194/0x13c8 kernel/fork.c:2500<br /> kernel_thread+0xd4/0x110 kernel/fork.c:2552<br /> rest_init+0x44/0x4a0 init/main.c:687<br /> arch_call_rest_init+0x1c/0x28<br /> start_kernel+0x520/0x554 init/main.c:1064<br /> 0x0<br /> <br /> Freed by task 270:<br /> slab_free_hook mm/slub.c:1562 [inline]<br /> slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600<br /> slab_free mm/slub.c:3161 [inline]<br /> kmem_cache_free+0x224/0x8e0 mm/slub.c:3177<br /> put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114<br /> put_pid+0x30/0x48 kernel/pid.c:109<br /> proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401<br /> proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591<br /> proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617<br /> call_write_iter include/linux/fs.h:1977 [inline]<br /> new_sync_write+0x3ac/0x510 fs/read_write.c:518<br /> vfs_write fs/read_write.c:605 [inline]<br /> vfs_write+0x9c4/0x1018 fs/read_write.c:585<br /> ksys_write+0x124/0x240 fs/read_write.c:658<br /> __do_sys_write fs/read_write.c:670 [inline]<br /> __se_sys_write fs/read_write.c:667 [inline]<br /> __arm64_sys_write+0x78/0xb0 fs/read_write.c:667<br /> __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]<br /> invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]<br /> el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129<br /> do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168<br /> el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416<br /> el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432<br /> el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701<br /> <br /> The buggy address belongs to the object at ffff23794dda0000<br /> which belongs to the cache pid of size 224<br /> The buggy address is located 4 bytes inside of<br /> 224-byte region [ff<br /> ---truncated---

OpenMetadata is a unified platform for discovery, observability, and governance powered by a central metadata repository, in-depth lineage, and seamless team collaboration. The `‎AlertUtil::validateExpression` method evaluates an SpEL expression using `getValue` which by default uses the `StandardEvaluationContext`, allowing the expression to reach and interact with Java classes such as `java.lang.Runtime`, leading to Remote Code Execution. The `/api/v1/events/subscriptions/validation/condition/` endpoint passes user-controlled data `AlertUtil::validateExpession` allowing authenticated (non-admin) users to execute arbitrary system commands on the underlaying operating system. In addition, there is a missing authorization check since `Authorizer.authorize()` is never called in the affected path and, therefore, any authenticated non-admin user is able to trigger this endpoint and evaluate arbitrary SpEL expressions leading to arbitrary command execution. This vulnerability was discovered with the help of CodeQL&amp;#39;s Expression language injection (Spring) query and is also tracked as `GHSL-2023-235`. This issue may lead to Remote Code Execution and has been addressed in version 1.2.4. Users are advised to upgrade. There are no known workarounds for this vulnerability.

OpenMetadata is a unified platform for discovery, observability, and governance powered by a central metadata repository, in-depth lineage, and seamless team collaboration. The `JwtFilter` handles the API authentication by requiring and verifying JWT tokens. When a new request comes in, the request&amp;#39;s path is checked against this list. When the request&amp;#39;s path contains any of the excluded endpoints the filter returns without validating the JWT. Unfortunately, an attacker may use Path Parameters to make any path contain any arbitrary strings. For example, a request to `GET /api/v1;v1%2fusers%2flogin/events/subscriptions/validation/condition/111` will match the excluded endpoint condition and therefore will be processed with no JWT validation allowing an attacker to bypass the authentication mechanism and reach any arbitrary endpoint, including the ones listed above that lead to arbitrary SpEL expression injection. This bypass will not work when the endpoint uses the `SecurityContext.getUserPrincipal()` since it will return `null` and will throw an NPE. This issue may lead to authentication bypass and has been addressed in version 1.2.4. Users are advised to upgrade. There are no known workarounds for this vulnerability. This issue is also tracked as `GHSL-2023-237`.

OpenMetadata is a unified platform for discovery, observability, and governance powered by a central metadata repository, in-depth lineage, and seamless team collaboration. Similarly to the GHSL-2023-250 issue, `AlertUtil::validateExpression` is also called from `EventSubscriptionRepository.prepare()`, which can lead to Remote Code Execution. `prepare()` is called from `EntityRepository.prepareInternal()` which, in turn, gets called from `EntityResource.createOrUpdate()`. Note that, even though there is an authorization check (`authorizer.authorize()`), it gets called after `prepareInternal()` gets called and, therefore, after the SpEL expression has been evaluated. In order to reach this method, an attacker can send a PUT request to `/api/v1/events/subscriptions` which gets handled by `EventSubscriptionResource.createOrUpdateEventSubscription()`. This vulnerability was discovered with the help of CodeQL&amp;#39;s Expression language injection (Spring) query. This issue may lead to Remote Code Execution and has been addressed in version 1.2.4. Users are advised to upgrade. There are no known workarounds for this vulnerability. This issue is also tracked as `GHSL-2023-251`.

OpenMetadata is a unified platform for discovery, observability, and governance powered by a central metadata repository, in-depth lineage, and seamless team collaboration. The `‎CompiledRule::validateExpression` method evaluates an SpEL expression using an `StandardEvaluationContext`, allowing the expression to reach and interact with Java classes such as `java.lang.Runtime`, leading to Remote Code Execution. The `/api/v1/policies/validation/condition/` endpoint passes user-controlled data `CompiledRule::validateExpession` allowing authenticated (non-admin) users to execute arbitrary system commands on the underlaying operating system. In addition, there is a missing authorization check since `Authorizer.authorize()` is never called in the affected path and therefore any authenticated non-admin user is able to trigger this endpoint and evaluate arbitrary SpEL expressions leading to arbitrary command execution. This vulnerability was discovered with the help of CodeQL&amp;#39;s Expression language injection (Spring) query and is also tracked as `GHSL-2023-236`. This issue may lead to Remote Code Execution and has been resolved in version 1.2.4. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Discourse is an open source platform for community discussion. In affected versions an attacker can learn that secret categories exist when they have backgrounds set. The issue is patched in the latest stable, beta and tests-passed version of Discourse. Users are advised to upgrade. Users unable to upgrade should temporarily remove category backgrounds.

OpenMetadata is a unified platform for discovery, observability, and governance powered by a central metadata repository, in-depth lineage, and seamless team collaboration. `CompiledRule::validateExpression` is also called from `PolicyRepository.prepare`. `prepare()` is called from `EntityRepository.prepareInternal()` which, in turn, gets called from `EntityResource.createOrUpdate()`. Note that even though there is an authorization check (`authorizer.authorize()`), it gets called after `prepareInternal()` gets called and therefore after the SpEL expression has been evaluated. In order to reach this method, an attacker can send a PUT request to `/api/v1/policies` which gets handled by `PolicyResource.createOrUpdate()`. This vulnerability was discovered with the help of CodeQL&amp;#39;s Expression language injection (Spring) query and is also tracked as `GHSL-2023-252`. This issue may lead to Remote Code Execution and has been addressed in version 1.3.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.

In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.