huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2025-22113: kernel: ext4: avoid journaling sb update on error if journal is destroying
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid journaling sb update on error if journal is destroying

Presently we always BUG_ON if trying to start a transaction on a journal marked
with JBD2_UNMOUNT, since this should never happen. However, while ltp running
stress tests, it was observed that in case of some error handling paths, it is
possible for update_super_work to start a transaction after the journal is
destroyed eg:

(umount)
ext4_kill_sb
  kill_block_super
    generic_shutdown_super
      sync_filesystem /* commits all txns */
      evict_inodes
        /* might start a new txn */
      ext4_put_super
	flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */
        jbd2_journal_destroy
          journal_kill_thread
            journal->j_flags |= JBD2_UNMOUNT;
          jbd2_journal_commit_transaction
            jbd2_journal_get_descriptor_buffer
              jbd2_journal_bmap
                ext4_journal_bmap
                  ext4_map_blocks
                    ...
                    ext4_inode_error
                      ext4_handle_error
                        schedule_work(&sbi->s_sb_upd_work)

                                               /* work queue kicks in */
                                               update_super_work
                                                 jbd2_journal_start
                                                   start_this_handle
                                                     BUG_ON(journal->j_flags &
                                                            JBD2_UNMOUNT)

Hence, introduce a new mount flag to indicate journal is destroying and only do
a journaled (and deferred) update of sb if this flag is not set. Otherwise, just
fallback to an un-journaled commit.

Further, in the journal destroy path, we have the following sequence:

  1. Set mount flag indicating journal is destroying
  2. force a commit and wait for it
  3. flush pending sb updates

This sequence is important as it ensures that, after this point, there is no sb
update that might be journaled so it is safe to update the sb outside the
journal. (To avoid race discussed in 2d01ddc86606)

Also, we don't need a similar check in ext4_grp_locked_error since it is only
called from mballoc and AFAICT it would be always valid to schedule work here.


Affected upstream versions: 5.11
Fixed upstream versions: 0, 6.12.46, 6.14.2, 6.15
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: eddca44ddf810e27f0c96913aa3cc92ebd679ddb
CVE-2025-22116: kernel: idpf: check error for register_netdev() on init
Component: kernel
Severity: Low
CWE: CWE-253 (Incorrect Check of Function Return Value)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

idpf: check error for register_netdev() on init

Current init logic ignores the error code from register_netdev(),
which will cause WARN_ON() on attempt to unregister it, if there was one,
and there is no info for the user that the creation of the netdev failed.

WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10
...
[ 3707.563641]  unregister_netdev+0x1c/0x30
[ 3707.563656]  idpf_vport_dealloc+0x5cf/0xce0 [idpf]
[ 3707.563684]  idpf_deinit_task+0xef/0x160 [idpf]
[ 3707.563712]  idpf_vc_core_deinit+0x84/0x320 [idpf]
[ 3707.563739]  idpf_remove+0xbf/0x780 [idpf]
[ 3707.563769]  pci_device_remove+0xab/0x1e0
[ 3707.563786]  device_release_driver_internal+0x371/0x530
[ 3707.563803]  driver_detach+0xbf/0x180
[ 3707.563816]  bus_remove_driver+0x11b/0x2a0
[ 3707.563829]  pci_unregister_driver+0x2a/0x250

Introduce an error check and log the vport number and error code.
On removal make sure to check VPORT_REG_NETDEV flag prior to calling
unregister and free on the netdev.

Add local variables for idx, vport_config and netdev for readability.


Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.12.80, 6.14.2, 6.15
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1ca996324eacab8fdb7c8ac231eebe5ef0c3c454
CVE-2025-22121: kernel: ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()

There's issue as follows:
BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790
Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172

CPU: 3 PID: 15172 Comm: syz-executor.0
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 dump_stack+0xbe/0xfd lib/dump_stack.c:123
 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137
 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896
 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323
 evict+0x39f/0x880 fs/inode.c:622
 iput_final fs/inode.c:1746 [inline]
 iput fs/inode.c:1772 [inline]
 iput+0x525/0x6c0 fs/inode.c:1758
 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline]
 ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300
 mount_bdev+0x355/0x410 fs/super.c:1446
 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611
 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576
 do_new_mount fs/namespace.c:2983 [inline]
 path_mount+0x119a/0x1ad0 fs/namespace.c:3316
 do_mount+0xfc/0x110 fs/namespace.c:3329
 __do_sys_mount fs/namespace.c:3540 [inline]
 __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x67/0xd1

Memory state around the buggy address:
 ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
                   ^
 ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Above issue happens as ext4_xattr_delete_inode() isn't check xattr
is valid if xattr is in inode.
To solve above issue call xattr_check_inode() check if xattr if valid
in inode. In fact, we can directly verify in ext4_iget_extra_inode(),
so that there is no divergent verification.


Affected upstream versions: 4.13
Fixed upstream versions: 0, 5.10.248, 5.15.198, 6.1.161, 6.12.59, 6.14.2, 6.15, 6.6.120
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 27202452b0bc942fdc3db72a44c4dcdab96d5b56
CVE-2025-22122: kernel: block: fix adding folio to bio
Component: kernel
Severity: Moderate
CWE: CWE-190 (Integer Overflow or Wraparound)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

block: fix adding folio to bio

>4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage
is supported, then 'offset' of folio can't be held in 'unsigned int',
cause warning in bio_add_folio_nofail() and IO failure.

Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't
be overflow, and folio can be added to bio successfully.


Affected upstream versions: 6.12
Fixed upstream versions: 0, 6.12.33, 6.14.2, 6.15
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0c60158ff14df04c92792dd9b1809372b095040f
CVE-2025-22126: kernel: md: fix mddev uaf while iterating all_mddevs list
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-04-16T00:00:00+00:00

A flaw was discovered in the Linux kernel’s MD (multiple device) subsystem during iteration over the all_mddevs list in functions such as md_notify_reboot() and md_exit(). The code used list_for_each_entry_safe, but released locks before completing reference counting, allowing concurrent deletion and freeing of an mddev entry. This led to a use-after-free when the kernel continued to reference freed mddev structures. A local user with low privileges could trigger this to corrupt memory and cause a denial of service. The issue has been resolved by reworking the iteration logic, introducing proper locking and reference handling (mddev_put_locked()), and switching to list_for_each_entry to avoid unsafe continuation across deletions


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.135, 6.12.25, 6.14.2, 6.15, 6.6.88
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ca9f84de76723b358dfc0606668efdca54afc2e5
CVE-2025-22150: undici: Undici Uses Insufficiently Random Values
Component: undici
Severity: Moderate
CWE: CWE-330 (Use of Insufficiently Random Values)
CVSS v3: 6.8 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N)
Public date: 2025-01-21T17:46:58.872000+00:00

A flaw was found in the undici package for Node.js. Undici uses `Math.random()` to choose the boundary for a multipart/form-data request. It is known that the output of `Math.random()` can be predicted if several of its generated values are known. If an app has a mechanism that sends multipart requests to an attacker-controlled website, it can leak the necessary values. Therefore, an attacker can tamper with the requests going to the backend APIs if certain conditions are met.


Affected upstream versions: >= 4.5.0, < 5.28.5, >= 6.0.0, < 6.21.1, >= 7.0.0, < 7.2.3
Fixed upstream versions: v5.28.5
Upstream repository: https://github.com/nodejs/undici
Upstream fix commit: 711e20772764c29f6622ddc937c63b6eefdf07d0
CVE-2025-23129: kernel: wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path
Component: kernel
Severity: Low
CWE: CWE-459 (Incomplete Cleanup)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path

If a shared IRQ is used by the driver due to platform limitation, then the
IRQ affinity hint is set right after the allocation of IRQ vectors in
ath11k_pci_alloc_msi(). This does no harm unless one of the functions
requesting the IRQ fails and attempt to free the IRQ. This results in the
below warning:

WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c
Call trace:
 free_irq+0x278/0x29c
 ath11k_pcic_free_irq+0x70/0x10c [ath11k]
 ath11k_pci_probe+0x800/0x820 [ath11k_pci]
 local_pci_probe+0x40/0xbc

The warning is due to not clearing the affinity hint before freeing the
IRQs.

So to fix this issue, clear the IRQ affinity hint before calling
ath11k_pcic_free_irq() in the error path. The affinity will be cleared once
again further down the error path due to code organization, but that does
no harm.

Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1


Affected upstream versions: 6.1.63 < 6.2, 6.5.12 < 6.6, 6.6.2 < 6.7, 6.7
Fixed upstream versions: 0, 6.12.59, 6.14.2, 6.15, 6.2, 6.6, 6.7
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 80dc5a2ce5b75d648e08549617f5c555d07ae43c
CVE-2025-23142: kernel: Linux kernel: SCTP use-after-free due to race condition in sendmsg
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 7.5 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

A flaw was found in the Linux kernel's SCTP implementation. This vulnerability allows a use-after-free read via a race condition during SCTP message sending.

Statement: This is a MODERATE impact use-after-free flaw,found in the Linux kernel's Stream Control Transmission Protocol (SCTP) implementation. This race condition occurs during message sending,the kernel function sctp_sendmsg() sends SCTP messages by selecting a transport (network path) and associating it with message chunks.
If another thread removes that transport (e.g., by unbinding an address using setsockopt(SCTP_SOCKOPT_BINDX_REM)) after the transport has been selected but before the message is sent, the code can end up accessing a transport that has been freed from memory, leading to a use after free. Red Hat Enterprise Linux 9 is affected. Red Hat Enterprise Linux 10 and Red Hat In-Vehicle OS are not affected as the vulnerable code is not present.

Affected upstream versions: 3.18.128 < 3.19, 4.4.166 < 4.5, 4.9.142 < 4.10, 4.14.85 < 4.15, 4.19.6 < 4.20, 4.20
Fixed upstream versions: 0, 3.19, 4.10, 4.15, 4.20, 4.5, 5.10.237, 5.15.181, 5.4.293, 6.1.135, 6.12.24, 6.13.12, 6.14.3, 6.15, 6.6.88
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 547762250220325d350d0917a7231480e0f4142b
CVE-2025-23150: kernel: ext4: fix off-by-one error in do_split
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-05-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix off-by-one error in do_split

Syzkaller detected a use-after-free issue in ext4_insert_dentry that was
caused by out-of-bounds access due to incorrect splitting in do_split.

BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847

CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106
 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109
 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154
 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351
 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455
 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796
 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431
 vfs_symlink+0x137/0x2e0 fs/namei.c:4615
 do_symlinkat+0x222/0x3a0 fs/namei.c:4641
 __do_sys_symlink fs/namei.c:4662 [inline]
 __se_sys_symlink fs/namei.c:4660 [inline]
 __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 </TASK>

The following loop is located right above 'if' statement.

for (i = count-1; i >= 0; i--) {
	/* is more than half of this entry in 2nd half of the block? */
	if (size + map[i].size/2 > blocksize/2)
		break;
	size += map[i].size;
	move++;
}

'i' in this case could go down to -1, in which case sum of active entries
wouldn't exceed half the block size, but previous behaviour would also do
split in half if sum would exceed at the very last block, which in case of
having too many long name files in a single block could lead to
out-of-bounds access and following use-after-free.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.


Affected upstream versions: 5.4.61 < 5.4.293, 4.4.234 < 4.5, 4.9.234 < 4.10, 4.14.195 < 4.15, 4.19.142 < 4.20, 5.7.18 < 5.8, 5.8.4 < 5.9, 5.9
Fixed upstream versions: 0, 4.10, 4.15, 4.20, 4.5, 5.10.237, 5.15.181, 5.4.293, 5.8, 5.9, 6.1.135, 6.12.24, 6.13.12, 6.14.3, 6.15, 6.6.88
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b96bd2c3db26ad0daec5b78c85c098b53900e2e1
CVE-2025-23207: katex: \htmlData does not validate attribute names in KaTeX
Component: katex
Severity: Moderate
CWE: CWE-116 (Improper Encoding or Escaping of Output)
CVSS v3: 6.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L)
Public date: 2025-01-17T21:25:05.746000+00:00

A flaw was found in the KaTeX library. KaTeX users who render untrusted mathematical expressions with `renderToString` could encounter malicious input using `\htmlData` that runs arbitrary JavaScript or generate invalid HTML.


Affected upstream versions: >= 0.12.0, < 0.16.21
Fixed upstream versions: v0.16.21
Upstream repository: https://github.com/KaTeX/KaTeX
Upstream fix commit: ff289955e81aab89086eef09254cbf88573d415c
CVE-2025-23216: argocd: Argo CD does not scrub secret values from patch errors
Component: argocd
Severity: Moderate
CWE: CWE-209 (Generation of Error Message Containing Sensitive Information)
CVSS v3: 6.8 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N)
Public date: 2025-01-30T15:30:05.405000+00:00

A vulnerability was found in Argo CD where secret values can be exposed in error messages when an invalid Kubernetes Secret resource is synced from a repository. An attacker must have write access to the repository and any user with read access can view the exposed data.


Affected upstream versions: >= 2.13.0, < 2.13.4, >= 2.12.0, < 2.12.10, < 2.11.13
Fixed upstream versions: v3.0.0
Upstream repository: https://github.com/argoproj/argo-cd
Upstream fix commit: 6f5537bdf15ddbaa0f27a1a678632ff0743e4107
CVE-2025-24528: krb5: overflow when calculating ulog block size
Component: krb5
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-01-28T00:00:00+00:00

A flaw was found in krb5. With incremental propagation enabled, an authenticated attacker can cause kadmind to write beyond the end of the mapped region for the iprop log file. This issue can trigger a process crash and lead to a denial of service.


Affected upstream versions: 1.7 < 1.22
Fixed upstream versions: 1.22
Upstream repository: https://github.com/krb5/krb5
Upstream fix commit: 78ceba024b64d49612375be4a12d1c066b0bfbd0
CVE-2025-24970: io.netty:netty-handler: SslHandler doesn't correctly validate packets which can lead to native crash when using native SSLEngine
Component: io.netty
Severity: Important
CWE: CWE-20 (Improper Input Validation)
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-10T21:57:28.730000+00:00

A flaw was found in Netty's SslHandler. This vulnerability allows a native crash via a specially crafted packet that bypasses proper validation.

Statement: This vulnerability in Netty's SslHandler is of important severity rather than moderate because it directly impacts the stability and reliability of applications using native SSLEngine. By sending a specially crafted packet, an attacker can trigger a native crash, leading to a complete process termination. Unlike typical moderate vulnerabilities that might cause limited disruptions or require specific conditions, this flaw can be exploited remotely to induce a Denial of Service (DoS), affecting high-availability systems and mission-critical services.

Affected upstream versions: >= 4.1.91.Final, <= 4.1.117.Final
Fixed upstream versions: netty-4.1.118.Final
Upstream repository: https://github.com/netty/netty
Upstream fix commit: 87f40725155b2f89adfde68c7732f97c153676c4
CVE-2025-24976: distribution: Distribution's token authentication allows attacker to inject an untrusted signing key in a JWT
Component: distribution
Severity: Moderate
CWE: CWE-639 (Authorization Bypass Through User-Controlled Key)
CVSS v3: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N)
Public date: 2025-02-11T15:48:59.700000+00:00

A flaw was found in Distribution. Certain versions with token authentication enabled may be vulnerable to an issue where token authentication allows an attacker to inject an untrusted signing key in a JSON web token (JWT). The issue is due to how the JSON web key (JWK) verification is performed. When a JWT contains a JWK header without a certificate chain, the code only checks if the KeyID (`kid`) matches one of the trusted keys but doesn't verify that the key material matches.


Affected upstream versions: >= 3.0.0-beta.1, <= 3.0.0-rc.2
Fixed upstream versions: v3.0.0
Upstream repository: https://github.com/distribution/distribution
Upstream fix commit: 5ea9aa028db65ca5665f6af2c20ecf9dc34e5fcd
CVE-2025-25184: rubygem-rack: Possible Log Injection in Rack::CommonLogger
Component: rubygem-rack
Severity: Moderate
CWE: CWE-117 (Improper Output Neutralization for Logs)
CVSS v3: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N)
Public date: 2025-02-12T16:20:46.865000+00:00

A flaw was found in the rubygem-rack package. When a user provides the authorization credentials via Rack::Auth::Basic, if successful, the username is placed in env['REMOTE_USER'] and later used by Rack::CommonLogger for logging purposes. The issue occurs when a server intentionally or unintentionally allows a user creation with the username containing CRLF and white space characters or the server logs every login attempt. If an attacker enters a username with a CRLF character, the logger will log the malicious username with CRLF characters into the logfile. This flaw allows attackers to break log formats or insert fraudulent entries, potentially obscuring activity or injecting malicious data into log files.


Affected upstream versions: < 2.2.11, >= 3.0, < 3.0.12, >= 3.1, < 3.1.10
Fixed upstream versions: v3.2.0
Upstream repository: https://github.com/rack/rack
Upstream fix commit: 074ae244430cda05c27ca91cda699709cfb3ad8e
CVE-2025-25186: net-imap: Net::IMAP vulnerable to possible DoS by memory exhaustion
Component: net-imap
Severity: Moderate
CWE: CWE-770 (Allocation of Resources Without Limits or Throttling)
CVSS v3: 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H)
Public date: 2025-02-10T15:55:56.666000+00:00

A flaw was found in Ruby's net-imap library. In certain versions, there is a possibility for denial of service by memory exhaustion in the `net-imap` response parser. At any time while the client is connected, a malicious server can send highly compressed `uid-set` data, which is automatically read by the client's receiver thread. The response parser converts the `uid-set` data into arrays of integers with no limitation on the expanded size of the ranges, which can trigger memory exhaustion.


Affected upstream versions: >= 0.3.2, < 0.3.8, >= 0.4.0, < 0.4.19, >= 0.5.0, < 0.5.6
Fixed upstream versions: v0.5.6
Upstream repository: https://github.com/ruby/net-imap
Upstream fix commit: 70e3ddd071a94e450b3238570af482c296380b35
CVE-2025-25193: netty: Denial of Service attack on windows app using Netty
Component: netty
Severity: Moderate
CWE: CWE-400 (Uncontrolled Resource Consumption)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-10T22:02:17.197000+00:00

A flaw was found in Netty. An unsafe reading of the environment file could cause a denial of service. When loaded on a Windows application, Netty attempts to load a file that does not exist. If an attacker creates a large file, the Netty application crash.

Statement: This issue only affects Windows environments, therefore, this would affect an environment when running a supported Red Hat JBoss EAP 7 or 8, for example, if running on Windows.

Affected upstream versions: <= 4.1.118
Fixed upstream versions: netty-4.1.118.Final
Upstream repository: https://github.com/netty/netty
Upstream fix commit: d1fbda62d3a47835d3fb35db8bd42ecc205a5386