Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix a NULL pointer dereference when failed to start a new trasacntion<br /> <br /> [BUG]<br /> Syzbot reported a NULL pointer dereference with the following crash:<br /> <br /> FAULT_INJECTION: forcing a failure.<br /> start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676<br /> prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642<br /> relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678<br /> ...<br /> BTRFS info (device loop0): balance: ended with status: -12<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]<br /> RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926<br /> Call Trace:<br /> <br /> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496<br /> btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430<br /> del_balance_item fs/btrfs/volumes.c:3678 [inline]<br /> reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742<br /> btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574<br /> btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> [CAUSE]<br /> The allocation failure happens at the start_transaction() inside<br /> prepare_to_relocate(), and during the error handling we call<br /> unset_reloc_control(), which makes fs_info-&gt;balance_ctl to be NULL.<br /> <br /> Then we continue the error path cleanup in btrfs_balance() by calling<br /> reset_balance_state() which will call del_balance_item() to fully delete<br /> the balance item in the root tree.<br /> <br /> However during the small window between set_reloc_contrl() and<br /> unset_reloc_control(), we can have a subvolume tree update and created a<br /> reloc_root for that subvolume.<br /> <br /> Then we go into the final btrfs_commit_transaction() of<br /> del_balance_item(), and into btrfs_update_reloc_root() inside<br /> commit_fs_roots().<br /> <br /> That function checks if fs_info-&gt;reloc_ctl is in the merge_reloc_tree<br /> stage, but since fs_info-&gt;reloc_ctl is NULL, it results a NULL pointer<br /> dereference.<br /> <br /> [FIX]<br /> Just add extra check on fs_info-&gt;reloc_ctl inside<br /> btrfs_update_reloc_root(), before checking<br /> fs_info-&gt;reloc_ctl-&gt;merge_reloc_tree.<br /> <br /> That DEAD_RELOC_TREE handling is to prevent further modification to the<br /> reloc tree during merge stage, but since there is no reloc_ctl at all,<br /> we do not need to bother that.

A stored cross-site scripting (XSS) vulnerability in HikaShop Joomla Component

Nginx UI is a web user interface for the Nginx web server. Nginx UI v2.0.0-beta.35 and earlier gets the value from the json field without verification, and can construct a value value in the form of `../../`. Arbitrary files can be written to the server, which may result in loss of permissions. Version 2.0.0-beta.26 fixes the issue.

Nginx UI is a web user interface for the Nginx web server. Prior to version 2.0.0-beta.36, the log path of nginxui is controllable. This issue can be combined with the directory traversal at `/api/configs` to read directories and file contents on the server. Version 2.0.0-beta.36 fixes the issue.

Nginx UI is a web user interface for the Nginx web server. Prior to version 2.0.0-beta.36, when Nginx UI configures logrotate, it does not verify the input and directly passes it to exec.Command, causing arbitrary command execution. Version 2.0.0-beta.36 fixes this issue.

secp256k1-node is a Node.js binding for an Optimized C library for EC operations on curve secp256k1. In `elliptic`-based version, `loadUncompressedPublicKey` has a check that the public key is on the curve. Prior to versions 5.0.1, 4.0.4, and 3.8.1, however, `loadCompressedPublicKey` is missing that check. That allows the attacker to use public keys on low-cardinality curves to extract enough information to fully restore the private key from as little as 11 ECDH sessions, and very cheaply on compute power. Other operations on public keys are also affected, including e.g. `publicKeyVerify()` incorrectly returning `true` on those invalid keys, and e.g. `publicKeyTweakMul()` also returning predictable outcomes allowing to restore the tweak. Versions 5.0.1, 4.0.4, and 3.8.1 contain a fix for the issue.

prepareUnique index may cause secondaries to crash due to incorrect enforcement of index constraints on secondaries, where in extreme cases may cause multiple secondaries crashing leading to no primaries. This issue affects MongoDB Server v6.0 versions prior to 6.0.17, MongoDB Server v7.0 versions prior to 7.0.13 and MongoDB Server v7.3 versions prior to 7.3.4

OneDev is a Git server with CI/CD, kanban, and packages. A vulnerability in versions prior to 11.0.9 allows unauthenticated users to read arbitrary files accessible by the OneDev server process. This issue has been fixed in version 11.0.9.

A use-after-free vulnerability was found in the QEMU LSI53C895A SCSI Host Bus Adapter emulation. This issue can lead to a crash or VM escape.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: set the cipher for secured NDP ranging<br /> <br /> The cipher pointer is not set, but is derefereced trying to set its<br /> content, which leads to a NULL pointer dereference.<br /> Fix it by pointing to the cipher parameter before dereferencing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powercap: intel_rapl: Fix off by one in get_rpi()<br /> <br /> The rp-&gt;priv-&gt;rpi array is either rpi_msr or rpi_tpmi which have<br /> NR_RAPL_PRIMITIVES number of elements. Thus the &gt; needs to be &gt;=<br /> to prevent an off by one access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix helper writes to read-only maps<br /> <br /> Lonial found an issue that despite user- and BPF-side frozen BPF map<br /> (like in case of .rodata), it was still possible to write into it from<br /> a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}<br /> as arguments.<br /> <br /> In check_func_arg() when the argument is as mentioned, the meta-&gt;raw_mode<br /> is never set. Later, check_helper_mem_access(), under the case of<br /> PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the<br /> subsequent call to check_map_access_type() and given the BPF map is<br /> read-only it succeeds.<br /> <br /> The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT<br /> when results are written into them as opposed to read out of them. The<br /> latter indicates that it&amp;#39;s okay to pass a pointer to uninitialized memory<br /> as the memory is written to anyway.<br /> <br /> However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM<br /> just with additional alignment requirement. So it is better to just get<br /> rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the<br /> fixed size memory types. For this, add MEM_ALIGNED to additionally ensure<br /> alignment given these helpers write directly into the args via * = val.<br /> The .arg*_size has been initialized reflecting the actual sizeof(*).<br /> <br /> MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated<br /> argument types, since in !MEM_FIXED_SIZE cases the verifier does not know<br /> the buffer size a priori and therefore cannot blindly write * = val.