Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do proper folio cleanup when run_delalloc_nocow() failed<br /> <br /> [BUG]<br /> With CONFIG_DEBUG_VM set, test case generic/476 has some chance to crash<br /> with the following VM_BUG_ON_FOLIO():<br /> <br /> BTRFS error (device dm-3): cow_file_range failed, start 1146880 end 1253375 len 106496 ret -28<br /> BTRFS error (device dm-3): run_delalloc_nocow failed, start 1146880 end 1253375 len 106496 ret -28<br /> page: refcount:4 mapcount:0 mapping:00000000592787cc index:0x12 pfn:0x10664<br /> aops:btrfs_aops [btrfs] ino:101 dentry name(?):"f1774"<br /> flags: 0x2fffff80004028(uptodate|lru|private|node=0|zone=2|lastcpupid=0xfffff)<br /> page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/page-writeback.c:2992!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 2 UID: 0 PID: 3943513 Comm: kworker/u24:15 Tainted: G OE 6.12.0-rc7-custom+ #87<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022<br /> Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]<br /> pc : folio_clear_dirty_for_io+0x128/0x258<br /> lr : folio_clear_dirty_for_io+0x128/0x258<br /> Call trace:<br /> folio_clear_dirty_for_io+0x128/0x258<br /> btrfs_folio_clamp_clear_dirty+0x80/0xd0 [btrfs]<br /> __process_folios_contig+0x154/0x268 [btrfs]<br /> extent_clear_unlock_delalloc+0x5c/0x80 [btrfs]<br /> run_delalloc_nocow+0x5f8/0x760 [btrfs]<br /> btrfs_run_delalloc_range+0xa8/0x220 [btrfs]<br /> writepage_delalloc+0x230/0x4c8 [btrfs]<br /> extent_writepage+0xb8/0x358 [btrfs]<br /> extent_write_cache_pages+0x21c/0x4e8 [btrfs]<br /> btrfs_writepages+0x94/0x150 [btrfs]<br /> do_writepages+0x74/0x190<br /> filemap_fdatawrite_wbc+0x88/0xc8<br /> start_delalloc_inodes+0x178/0x3a8 [btrfs]<br /> btrfs_start_delalloc_roots+0x174/0x280 [btrfs]<br /> shrink_delalloc+0x114/0x280 [btrfs]<br /> flush_space+0x250/0x2f8 [btrfs]<br /> btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]<br /> process_one_work+0x164/0x408<br /> worker_thread+0x25c/0x388<br /> kthread+0x100/0x118<br /> ret_from_fork+0x10/0x20<br /> Code: 910a8021 a90363f7 a9046bf9 94012379 (d4210000)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [CAUSE]<br /> The first two lines of extra debug messages show the problem is caused<br /> by the error handling of run_delalloc_nocow().<br /> <br /> E.g. we have the following dirtied range (4K blocksize 4K page size):<br /> <br /> 0 16K 32K<br /> |//////////////////////////////////////|<br /> | Pre-allocated |<br /> <br /> And the range [0, 16K) has a preallocated extent.<br /> <br /> - Enter run_delalloc_nocow() for range [0, 16K)<br /> Which found range [0, 16K) is preallocated, can do the proper NOCOW<br /> write.<br /> <br /> - Enter fallback_to_fow() for range [16K, 32K)<br /> Since the range [16K, 32K) is not backed by preallocated extent, we<br /> have to go COW.<br /> <br /> - cow_file_range() failed for range [16K, 32K)<br /> So cow_file_range() will do the clean up by clearing folio dirty,<br /> unlock the folios.<br /> <br /> Now the folios in range [16K, 32K) is unlocked.<br /> <br /> - Enter extent_clear_unlock_delalloc() from run_delalloc_nocow()<br /> Which is called with PAGE_START_WRITEBACK to start page writeback.<br /> But folios can only be marked writeback when it&amp;#39;s properly locked,<br /> thus this triggered the VM_BUG_ON_FOLIO().<br /> <br /> Furthermore there is another hidden but common bug that<br /> run_delalloc_nocow() is not clearing the folio dirty flags in its error<br /> handling path.<br /> This is the common bug shared between run_delalloc_nocow() and<br /> cow_file_range().<br /> <br /> [FIX]<br /> - Clear folio dirty for range [@start, @cur_offset)<br /> Introduce a helper, cleanup_dirty_folios(), which<br /> will find and lock the folio in the range, clear the dirty flag and<br /> start/end the writeback, with the extra handling for the<br /> @locked_folio.<br /> <br /> - Introduce a helper to clear folio dirty, start and end writeback<br /> <br /> - Introduce a helper to record the last failed COW range end<br /> This is to trace which range we should skip, to avoid double<br /> unlocking.<br /> <br /> - Skip the failed COW range for the e<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do proper folio cleanup when cow_file_range() failed<br /> <br /> [BUG]<br /> When testing with COW fixup marked as BUG_ON() (this is involved with the<br /> new pin_user_pages*() change, which should not result new out-of-band<br /> dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW<br /> fixup path.<br /> <br /> This BUG_ON() happens just after a failed btrfs_run_delalloc_range():<br /> <br /> BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/extent_io.c:1444!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86<br /> Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022<br /> Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]<br /> pc : extent_writepage_io+0x2d4/0x308 [btrfs]<br /> lr : extent_writepage_io+0x2d4/0x308 [btrfs]<br /> Call trace:<br /> extent_writepage_io+0x2d4/0x308 [btrfs]<br /> extent_writepage+0x218/0x330 [btrfs]<br /> extent_write_cache_pages+0x1d4/0x4b0 [btrfs]<br /> btrfs_writepages+0x94/0x150 [btrfs]<br /> do_writepages+0x74/0x190<br /> filemap_fdatawrite_wbc+0x88/0xc8<br /> start_delalloc_inodes+0x180/0x3b0 [btrfs]<br /> btrfs_start_delalloc_roots+0x174/0x280 [btrfs]<br /> shrink_delalloc+0x114/0x280 [btrfs]<br /> flush_space+0x250/0x2f8 [btrfs]<br /> btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]<br /> process_one_work+0x164/0x408<br /> worker_thread+0x25c/0x388<br /> kthread+0x100/0x118<br /> ret_from_fork+0x10/0x20<br /> Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [CAUSE]<br /> That failure is mostly from cow_file_range(), where we can hit -ENOSPC.<br /> <br /> Although the -ENOSPC is already a bug related to our space reservation<br /> code, let&amp;#39;s just focus on the error handling.<br /> <br /> For example, we have the following dirty range [0, 64K) of an inode,<br /> with 4K sector size and 4K page size:<br /> <br /> 0 16K 32K 48K 64K<br /> |///////////////////////////////////////|<br /> |#######################################|<br /> <br /> Where |///| means page are still dirty, and |###| means the extent io<br /> tree has EXTENT_DELALLOC flag.<br /> <br /> - Enter extent_writepage() for page 0<br /> <br /> - Enter btrfs_run_delalloc_range() for range [0, 64K)<br /> <br /> - Enter cow_file_range() for range [0, 64K)<br /> <br /> - Function btrfs_reserve_extent() only reserved one 16K extent<br /> So we created extent map and ordered extent for range [0, 16K)<br /> <br /> 0 16K 32K 48K 64K<br /> |////////|//////////////////////////////|<br /> ||##############################|<br /> <br /> And range [0, 16K) has its delalloc flag cleared.<br /> But since we haven&amp;#39;t yet submit any bio, involved 4 pages are still<br /> dirty.<br /> <br /> - Function btrfs_reserve_extent() returns with -ENOSPC<br /> Now we have to run error cleanup, which will clear all<br /> EXTENT_DELALLOC* flags and clear the dirty flags for the remaining<br /> ranges:<br /> <br /> 0 16K 32K 48K 64K<br /> |////////| |<br /> | | |<br /> <br /> Note that range [0, 16K) still has its pages dirty.<br /> <br /> - Some time later, writeback is triggered again for the range [0, 16K)<br /> since the page range still has dirty flags.<br /> <br /> - btrfs_run_delalloc_range() will do nothing because there is no<br /> EXTENT_DELALLOC flag.<br /> <br /> - extent_writepage_io() finds page 0 has no ordered flag<br /> Which falls into the COW fixup path, triggering the BUG_ON().<br /> <br /> Unfortunately this error handling bug dates back to the introduction of<br /> btrfs. Thankfully with the abuse of COW fixup, at least it won&amp;#39;t crash<br /> the kernel.<br /> <br /> [FIX]<br /> Instead of immediately unlocking the extent and folios, we keep the extent<br /> and folios locked until either erroring out or the whole delalloc range<br /> finished.<br /> <br /> When the whole delalloc range finished without error, we just unlock the<br /> whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked<br /> cases)<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rdma/cxgb4: Prevent potential integer overflow on 32bit<br /> <br /> The "gl-&gt;tot_len" variable is controlled by the user. It comes from<br /> process_responses(). On 32bit systems, the "gl-&gt;tot_len + sizeof(struct<br /> cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an<br /> integer wrapping bug. Use size_add() to prevent this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Fix potential error pointer dereference in detach_pm()<br /> <br /> The proble is on the first line:<br /> <br /> if (jpeg-&gt;pd_dev[i] &amp;&amp; !pm_runtime_suspended(jpeg-&gt;pd_dev[i]))<br /> <br /> If jpeg-&gt;pd_dev[i] is an error pointer, then passing it to<br /> pm_runtime_suspended() will lead to an Oops. The other conditions<br /> check for both error pointers and NULL, but it would be more clear to<br /> use the IS_ERR_OR_NULL() check for that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memcg: fix soft lockup in the OOM process<br /> <br /> A soft lockup issue was found in the product with about 56,000 tasks were<br /> in the OOM cgroup, it was traversing them when the soft lockup was<br /> triggered.<br /> <br /> watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]<br /> CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G<br /> Hardware name: Huawei Cloud OpenStack Nova, BIOS<br /> RIP: 0010:console_unlock+0x343/0x540<br /> RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13<br /> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff<br /> RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247<br /> RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040<br /> R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0<br /> R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> vprintk_emit+0x193/0x280<br /> printk+0x52/0x6e<br /> dump_task+0x114/0x130<br /> mem_cgroup_scan_tasks+0x76/0x100<br /> dump_header+0x1fe/0x210<br /> oom_kill_process+0xd1/0x100<br /> out_of_memory+0x125/0x570<br /> mem_cgroup_out_of_memory+0xb5/0xd0<br /> try_charge+0x720/0x770<br /> mem_cgroup_try_charge+0x86/0x180<br /> mem_cgroup_try_charge_delay+0x1c/0x40<br /> do_anonymous_page+0xb5/0x390<br /> handle_mm_fault+0xc4/0x1f0<br /> <br /> This is because thousands of processes are in the OOM cgroup, it takes a<br /> long time to traverse all of them. As a result, this lead to soft lockup<br /> in the OOM process.<br /> <br /> To fix this issue, call &amp;#39;cond_resched&amp;#39; in the &amp;#39;mem_cgroup_scan_tasks&amp;#39;<br /> function per 1000 iterations. For global OOM, call<br /> &amp;#39;touch_softlockup_watchdog&amp;#39; per 1000 iterations to avoid this issue.

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

Unifiedtransform v2.X is vulnerable to Incorrect Access Control. Unauthorized users can access and manipulate endpoints intended exclusively for administrative use. This issue specifically affects teacher/edit/{id}.

When AdaCore Ada Web Server 25.0.0 is linked with GnuTLS, the default behaviour of AWS.Client is vulnerable to a man-in-the-middle attack because of lack of verification of an HTTPS server&amp;#39;s certificate (unless the using program specifies a TLS configuration).

Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. Reason: This candidate was issued in error. Notes: All references and descriptions in this candidate have been removed to prevent accidental usage.

TP-Link TL-WR845N devices with firmware TL-WR845N(UN)_V4_200909 and TL-WR845N(UN)_V4_190219 was discovered to contain a hardcoded password for the root account which can be obtained by analyzing downloaded firmware or via a brute force attack through physical access to the router. NOTE: The supplier has stated that this issue was fixed in firmware versions 250401 or later.

A Cross Site Scripting vulnerability in CloudClassroom-PHP Project v1.0 allows a remote attacker to execute arbitrary code via the exid parameter of the assessment function.

SunGrow iSolarCloud Android app V2.1.6.20241017 and prior uses an insecure AES key to encrypt client data (insufficient entropy). This may allow attackers to decrypt intercepted communications between the mobile app and iSolarCloud.