Vulnerabilities

The seffaflik thru 0.0.9 is vulnerable to symlink attacks due to incorrect default permissions given to the .kimlik file and .seffaflik file, which is created with mode 0777 and 0775 respectively, exposing secrets to other local users. Additionally, the .kimlik file is written without symlink checks, allowing local attackers to overwrite arbitrary files. This can result in information disclosure and denial of service.

TM2 Monitoring v3.04 contains an authentication bypass and plaintext credential disclosure.

Hugging Face Smolagents version 1.20.0 contains an XPath injection vulnerability in the search_item_ctrl_f function located in src/smolagents/vision_web_browser.py. The function constructs an XPath query by directly concatenating user-supplied input into the XPath expression without proper sanitization or escaping. This allows an attacker to inject malicious XPath syntax that can alter the intended query logic. The vulnerability enables attackers to bypass search filters, access unintended DOM elements, and disrupt web automation workflows. This can lead to information disclosure, manipulation of AI agent interactions, and compromise the reliability of automated web tasks. The issue is fixed in version 1.22.0.

In langgenius/dify-web version 1.6.0, the authentication mechanism reveals the existence of user accounts by returning different error messages for non-existent and existing accounts. Specifically, when a login or registration attempt is made with a non-existent username or email, the system responds with a message such as "account not found." Conversely, when the username or email exists but the password is incorrect, a different error message is returned. This discrepancy allows an attacker to enumerate valid user accounts by analyzing the error responses, potentially facilitating targeted social engineering, brute force, or credential stuffing attacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-timers: Ensure timer ID search-loop limit is valid<br /> <br /> posix_timer_add() tries to allocate a posix timer ID by starting from the<br /> cached ID which was stored by the last successful allocation.<br /> <br /> This is done in a loop searching the ID space for a free slot one by<br /> one. The loop has to terminate when the search wrapped around to the<br /> starting point.<br /> <br /> But that&amp;#39;s racy vs. establishing the starting point. That is read out<br /> lockless, which leads to the following problem:<br /> <br /> CPU0 CPU1<br /> posix_timer_add()<br /> start = sig-&gt;posix_timer_id;<br /> lock(hash_lock);<br /> ... posix_timer_add()<br /> if (++sig-&gt;posix_timer_id posix_timer_id;<br /> sig-&gt;posix_timer_id = 0;<br /> <br /> So CPU1 can observe a negative start value, i.e. -1, and the loop break<br /> never happens because the condition can never be true:<br /> <br /> if (sig-&gt;posix_timer_id == start)<br /> break;<br /> <br /> While this is unlikely to ever turn into an endless loop as the ID space is<br /> huge (INT_MAX), the racy read of the start value caught the attention of<br /> KCSAN and Dmitry unearthed that incorrectness.<br /> <br /> Rewrite it so that all id operations are under the hash lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: qmi_encdec: Restrict string length in decode<br /> <br /> The QMI TLV value for strings in a lot of qmi element info structures<br /> account for null terminated strings with MAX_LEN + 1. If a string is<br /> actually MAX_LEN + 1 length, this will cause an out of bounds access<br /> when the NULL character is appended in decoding.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_cost<br /> <br /> adjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabled<br /> when unlock. DEADLOCK might happen if we have held other locks and disabled<br /> IRQ before invoking it.<br /> <br /> Fix it by using spin_lock_irqsave() instead, which can keep IRQ state<br /> consistent with before when unlock.<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 5.10.0-02758-g8e5f91fd772f #26 Not tainted<br /> --------------------------------<br /> inconsistent {IN-HARDIRQ-W} -&gt; {HARDIRQ-ON-W} usage.<br /> kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes:<br /> ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq<br /> ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390<br /> {IN-HARDIRQ-W} state was registered at:<br /> __lock_acquire+0x3d7/0x1070<br /> lock_acquire+0x197/0x4a0<br /> __raw_spin_lock_irqsave<br /> _raw_spin_lock_irqsave+0x3b/0x60<br /> bfq_idle_slice_timer_body<br /> bfq_idle_slice_timer+0x53/0x1d0<br /> __run_hrtimer+0x477/0xa70<br /> __hrtimer_run_queues+0x1c6/0x2d0<br /> hrtimer_interrupt+0x302/0x9e0<br /> local_apic_timer_interrupt<br /> __sysvec_apic_timer_interrupt+0xfd/0x420<br /> run_sysvec_on_irqstack_cond<br /> sysvec_apic_timer_interrupt+0x46/0xa0<br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> irq event stamp: 837522<br /> hardirqs last enabled at (837521): [] __raw_spin_unlock_irqrestore<br /> hardirqs last enabled at (837521): [] _raw_spin_unlock_irqrestore+0x3d/0x40<br /> hardirqs last disabled at (837522): [] __raw_spin_lock_irq<br /> hardirqs last disabled at (837522): [] _raw_spin_lock_irq+0x43/0x50<br /> softirqs last enabled at (835852): [] __do_softirq+0x558/0x8ec<br /> softirqs last disabled at (835845): [] asm_call_irq_on_stack+0xf/0x20<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;bfqd-&gt;lock);<br /> <br /> lock(&amp;bfqd-&gt;lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 3 locks held by kworker/2:3/388:<br /> #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0<br /> #1: ffff8881176bfdd8 ((work_completion)(&amp;td-&gt;dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0<br /> #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: spin_lock_irq<br /> #2: ffff888118c00c28 (&amp;bfqd-&gt;lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390<br /> <br /> stack backtrace:<br /> CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Workqueue: kthrotld blk_throtl_dispatch_work_fn<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x107/0x167<br /> print_usage_bug<br /> valid_state<br /> mark_lock_irq.cold+0x32/0x3a<br /> mark_lock+0x693/0xbc0<br /> mark_held_locks+0x9e/0xe0<br /> __trace_hardirqs_on_caller<br /> lockdep_hardirqs_on_prepare.part.0+0x151/0x360<br /> trace_hardirqs_on+0x5b/0x180<br /> __raw_spin_unlock_irq<br /> _raw_spin_unlock_irq+0x24/0x40<br /> spin_unlock_irq<br /> adjust_inuse_and_calc_cost+0x4fb/0x970<br /> ioc_rqos_merge+0x277/0x740<br /> __rq_qos_merge+0x62/0xb0<br /> rq_qos_merge<br /> bio_attempt_back_merge+0x12c/0x4a0<br /> blk_mq_sched_try_merge+0x1b6/0x4d0<br /> bfq_bio_merge+0x24a/0x390<br /> __blk_mq_sched_bio_merge+0xa6/0x460<br /> blk_mq_sched_bio_merge<br /> blk_mq_submit_bio+0x2e7/0x1ee0<br /> __submit_bio_noacct_mq+0x175/0x3b0<br /> submit_bio_noacct+0x1fb/0x270<br /> blk_throtl_dispatch_work_fn+0x1ef/0x2b0<br /> process_one_work+0x83e/0x13f0<br /> process_scheduled_works<br /> worker_thread+0x7e3/0xd80<br /> kthread+0x353/0x470<br /> ret_from_fork+0x1f/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: fix potential deadlock in netlink_set_err()<br /> <br /> syzbot reported a possible deadlock in netlink_set_err() [1]<br /> <br /> A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs<br /> for netlink_lock_table()") in netlink_lock_table()<br /> <br /> This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()<br /> which were not covered by cited commit.<br /> <br /> [1]<br /> <br /> WARNING: possible irq lock inversion dependency detected<br /> 6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted<br /> <br /> syz-executor.2/23011 just changed the state of lock:<br /> ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612<br /> but this lock was taken by another, SOFTIRQ-safe lock in the past:<br /> (&amp;local-&gt;queue_stop_reason_lock){..-.}-{2:2}<br /> <br /> and interrupts could create inverse lock ordering between them.<br /> <br /> other info that might help us debug this:<br /> Possible interrupt unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(nl_table_lock);<br /> local_irq_disable();<br /> lock(&amp;local-&gt;queue_stop_reason_lock);<br /> lock(nl_table_lock);<br /> <br /> lock(&amp;local-&gt;queue_stop_reason_lock);<br /> <br /> *** DEADLOCK ***

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix NULL dereference in ni_write_inode<br /> <br /> Syzbot reports a NULL dereference in ni_write_inode.<br /> When creating a new inode, if allocation fails in mi_init function<br /> (called in mi_format_new function), mi-&gt;mrec is set to NULL.<br /> In the error path of this inode creation, mi-&gt;mrec is later<br /> dereferenced in ni_write_inode.<br /> <br /> Add a NULL check to prevent NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend<br /> <br /> sdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,<br /> driver unconditionally disables ecc_irq which is only enabled on<br /> those asics enabling sdma ecc. This will introduce a warning in<br /> suspend cycle on those chips with sdma ip v4.0, while without<br /> sdma ecc. So this patch correct this.<br /> <br /> [ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]<br /> [ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246<br /> [ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000<br /> [ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000<br /> [ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006<br /> [ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390<br /> [ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105<br /> [ 7283.167032] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000<br /> [ 7283.167036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0<br /> [ 7283.167041] Call Trace:<br /> [ 7283.167046] <br /> [ 7283.167048] sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu]<br /> [ 7283.167704] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]<br /> [ 7283.168296] amdgpu_device_suspend+0x103/0x180 [amdgpu]<br /> [ 7283.168875] amdgpu_pmops_freeze+0x21/0x60 [amdgpu]<br /> [ 7283.169464] pci_pm_freeze+0x54/0xc0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read()<br /> <br /> `req` is allocated in pcf50633_adc_async_read(), but<br /> adc_enqueue_request() could fail to insert the `req` into queue.<br /> We need to check the return value and free it in the case of failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe<br /> <br /> Smatch reports:<br /> drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()<br /> warn: &amp;#39;timer_baseaddr&amp;#39; from of_iomap() not released on lines: 498,508,516.<br /> <br /> timer_baseaddr may have the problem of not being released after use,<br /> I replaced it with the devm_of_iomap() function and added the clk_put()<br /> function to cleanup the "clk_ce" and "clk_cs".