Vulnerabilities

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sock: Prevent race in socket write iter and sock bind<br /> <br /> There is a potential race condition between sock bind and socket write<br /> iter. bind may free the same cmd via mgmt_pending before write iter sends<br /> the cmd, just as syzbot reported in UAF[1].<br /> <br /> Here we use hci_dev_lock to synchronize the two, thereby avoiding the<br /> UAF mentioned in [1].<br /> <br /> [1]<br /> syzbot reported:<br /> BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316<br /> Read of size 8 at addr ffff888077164818 by task syz.0.17/5989<br /> Call Trace:<br /> mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316<br /> set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918<br /> hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719<br /> hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> sock_write_iter+0x279/0x360 net/socket.c:1195<br /> <br /> Allocated by task 5989:<br /> mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296<br /> set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910<br /> hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719<br /> hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0x21c/0x270 net/socket.c:742<br /> sock_write_iter+0x279/0x360 net/socket.c:1195<br /> <br /> Freed by task 5991:<br /> mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]<br /> mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257<br /> mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477<br /> hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface<br /> <br /> When performing reset tests and encountering abnormal card drop issues<br /> that lead to a kernel crash, it is necessary to perform a null check<br /> before releasing resources to avoid attempting to release a null pointer.<br /> <br /> [ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)<br /> [ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]<br /> [ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 29.158162] pc : klist_remove+0x90/0x158<br /> [ 29.158174] lr : klist_remove+0x88/0x158<br /> [ 29.158180] sp : ffffffc0846b3c00<br /> [ 29.158185] pmr_save: 000000e0<br /> [ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058<br /> [ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0<br /> [ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290<br /> [ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781<br /> [ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428<br /> [ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018<br /> [ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000<br /> [ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d<br /> [ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e<br /> [ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c<br /> [ 29.158285] Call trace:<br /> [ 29.158290] klist_remove+0x90/0x158<br /> [ 29.158298] device_release_driver_internal+0x20c/0x268<br /> [ 29.158308] device_release_driver+0x1c/0x30<br /> [ 29.158316] usb_driver_release_interface+0x70/0x88<br /> [ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]<br /> [ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]<br /> [ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]<br /> [ 29.158430] process_scheduled_works+0x258/0x4e8<br /> [ 29.158441] worker_thread+0x300/0x428<br /> [ 29.158448] kthread+0x108/0x1d0<br /> [ 29.158455] ret_from_fork+0x10/0x20<br /> [ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297)<br /> [ 29.158474] ---[ end trace 0000000000000000 ]---<br /> [ 29.167129] Kernel panic - not syncing: Oops: Fatal exception<br /> [ 29.167144] SMP: stopping secondary CPUs<br /> [ 29.167158] ------------[ cut here ]------------