Vulnerabilidades

*** Pendiente de traducción *** WebsiteBaker 2.13.3 contains a stored cross-site scripting vulnerability that allows authenticated users to upload malicious SVG files with embedded JavaScript. Attackers can upload crafted SVG files with script tags that execute when the file is viewed, enabling persistent cross-site scripting attacks.

*** Pendiente de traducción *** phpfm 1.7.9 contains an authentication bypass vulnerability that allows attackers to log in by exploiting loose type comparison in password hash validation. Attackers can craft specific password hashes beginning with 0e or 00e to bypass authentication and upload malicious PHP files to the server.

*** Pendiente de traducción *** PimpMyLog 1.7.14 contains an improper access control vulnerability that allows remote attackers to create admin accounts without authorization through the configuration endpoint. Attackers can exploit the unsanitized username field to inject malicious JavaScript, create a hidden backdoor account, and potentially access sensitive server-side log information and environmental variables.

*** Pendiente de traducción *** Rukovoditel 3.4.1 contains multiple stored cross-site scripting vulnerabilities that allow authenticated attackers to inject malicious scripts. Attackers can insert XSS payloads in project task comments to execute arbitrary JavaScript in victim browsers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to detect potential corrupted nid in free_nid_list<br /> <br /> As reported, on-disk footer.ino and footer.nid is the same and<br /> out-of-range, let&amp;#39;s add sanity check on f2fs_alloc_nid() to detect<br /> any potential corruption in free_nid_list.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix invalid probe error return value<br /> <br /> After DME Link Startup, the error return value is set to the MIPI UniPro<br /> GenericErrorCode which can be 0 (SUCCESS) or 1 (FAILURE). Upon failure<br /> during driver probe, the error code 1 is propagated back to the driver<br /> probe function which must return a negative value to indicate an error,<br /> but 1 is not negative, so the probe is considered to be successful even<br /> though it failed. Subsequently, removing the driver results in an oops<br /> because it is not in a valid state.<br /> <br /> This happens because none of the callers of ufshcd_init() expect a<br /> non-negative error code.<br /> <br /> Fix the return value and documentation to match actual usage.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zctx: check chained notif contexts<br /> <br /> Send zc only links ubuf_info for requests coming from the same context.<br /> There are some ambiguous syz reports, so let&amp;#39;s check the assumption on<br /> notification completion.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: thead: th1520-ap: set all AXI clocks to CLK_IS_CRITICAL<br /> <br /> The AXI crossbar of TH1520 has no proper timeout handling, which means<br /> gating AXI clocks can easily lead to bus timeout and thus system hang.<br /> <br /> Set all AXI clock gates to CLK_IS_CRITICAL. All these clock gates are<br /> ungated by default on system reset.<br /> <br /> In addition, convert all current CLK_IGNORE_UNUSED usage to<br /> CLK_IS_CRITICAL to prevent unwanted clock gating.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netconsole: Acquire su_mutex before navigating configs hierarchy<br /> <br /> There is a race between operations that iterate over the userdata<br /> cg_children list and concurrent add/remove of userdata items through<br /> configfs. The update_userdata() function iterates over the<br /> nt-&gt;userdata_group.cg_children list, and count_extradata_entries() also<br /> iterates over this same list to count nodes.<br /> <br /> Quoting from Documentation/filesystems/configfs.rst:<br /> &gt; A subsystem can navigate the cg_children list and the ci_parent pointer<br /> &gt; to see the tree created by the subsystem. This can race with configfs&amp;#39;<br /> &gt; management of the hierarchy, so configfs uses the subsystem mutex to<br /> &gt; protect modifications. Whenever a subsystem wants to navigate the<br /> &gt; hierarchy, it must do so under the protection of the subsystem<br /> &gt; mutex.<br /> <br /> Without proper locking, if a userdata item is added or removed<br /> concurrently while these functions are iterating, the list can be<br /> accessed in an inconsistent state. For example, the list_for_each() loop<br /> can reach a node that is being removed from the list by list_del_init()<br /> which sets the nodes&amp;#39; .next pointer to point to itself, so the loop will<br /> never end (or reach the WARN_ON_ONCE in update_userdata() ).<br /> <br /> Fix this by holding the configfs subsystem mutex (su_mutex) during all<br /> operations that iterate over cg_children.<br /> This includes:<br /> - userdatum_value_store() which calls update_userdata() to iterate over<br /> cg_children<br /> - All sysdata_*_enabled_store() functions which call<br /> count_extradata_entries() to iterate over cg_children<br /> <br /> The su_mutex must be acquired before dynamic_netconsole_mutex to avoid<br /> potential lock ordering issues, as configfs operations may already hold<br /> su_mutex when calling into our code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lan966x: Fix sleeping in atomic context<br /> <br /> The following warning was seen when we try to connect using ssh to the device.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear<br /> preempt_count: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G W 6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE<br /> Tainted: [W]=WARN<br /> Hardware name: Generic DT based system<br /> Call trace:<br /> unwind_backtrace from show_stack+0x10/0x14<br /> show_stack from dump_stack_lvl+0x7c/0xac<br /> dump_stack_lvl from __might_resched+0x16c/0x2b0<br /> __might_resched from __mutex_lock+0x64/0xd34<br /> __mutex_lock from mutex_lock_nested+0x1c/0x24<br /> mutex_lock_nested from lan966x_stats_get+0x5c/0x558<br /> lan966x_stats_get from dev_get_stats+0x40/0x43c<br /> dev_get_stats from dev_seq_printf_stats+0x3c/0x184<br /> dev_seq_printf_stats from dev_seq_show+0x10/0x30<br /> dev_seq_show from seq_read_iter+0x350/0x4ec<br /> seq_read_iter from seq_read+0xfc/0x194<br /> seq_read from proc_reg_read+0xac/0x100<br /> proc_reg_read from vfs_read+0xb0/0x2b0<br /> vfs_read from ksys_read+0x6c/0xec<br /> ksys_read from ret_fast_syscall+0x0/0x1c<br /> Exception stack(0xf0b11fa8 to 0xf0b11ff0)<br /> 1fa0: 00000001 00001000 00000008 be9048d8 00001000 00000001<br /> 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001<br /> 1fe0: 0005404c be9048c0 00018684 b6ec2cd8<br /> <br /> It seems that we are using a mutex in a atomic context which is wrong.<br /> Change the mutex with a spinlock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> page_pool: always add GFP_NOWARN for ATOMIC allocations<br /> <br /> Driver authors often forget to add GFP_NOWARN for page allocation<br /> from the datapath. This is annoying to users as OOMs are a fact<br /> of life, and we pretty much expect network Rx to hit page allocation<br /> failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations<br /> by default.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Avoid crash due to unaligned access in unwinder<br /> <br /> Guenter Roeck reported this kernel crash on his emulated B160L machine:<br /> <br /> Starting network: udhcpc: started, v1.36.1<br /> Backtrace:<br /> [] unwind_once+0x1c/0x5c<br /> [] walk_stackframe.isra.0+0x74/0xb8<br /> [] arch_stack_walk+0x28/0x38<br /> [] stack_trace_save+0x48/0x5c<br /> [] set_track_prepare+0x44/0x6c<br /> [] ___slab_alloc+0xfc4/0x1024<br /> [] __slab_alloc.isra.0+0x58/0x90<br /> [] kmem_cache_alloc_noprof+0x2ac/0x4a0<br /> [] __anon_vma_prepare+0x60/0x280<br /> [] __vmf_anon_prepare+0x68/0x94<br /> [] do_wp_page+0x8cc/0xf10<br /> [] handle_mm_fault+0x6c0/0xf08<br /> [] do_page_fault+0x110/0x440<br /> [] handle_interruption+0x184/0x748<br /> [] schedule+0x4c/0x190<br /> BUG: spinlock recursion on CPU#0, ifconfig/2420<br /> lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0<br /> <br /> While creating the stack trace, the unwinder uses the stack pointer to guess<br /> the previous frame to read the previous stack pointer from memory. The crash<br /> happens, because the unwinder tries to read from unaligned memory and as such<br /> triggers the unalignment trap handler which then leads to the spinlock<br /> recursion and finally to a deadlock.<br /> <br /> Fix it by checking the alignment before accessing the memory.