Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: stm32/cryp - call finalize with bh disabled<br /> <br /> The finalize operation in interrupt mode produce a produces a spinlock<br /> recursion warning. The reason is the fact that BH must be disabled<br /> during this process.

Improper Neutralization of Special Elements used in an SQL Command (&amp;#39;SQL Injection&amp;#39;) vulnerability in TRtek Software Distant Education Platform allows SQL Injection, Parameter Injection.This issue affects Distant Education Platform: before 3.2024.11.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX<br /> <br /> [Why &amp; How]<br /> It actually exposes &amp;#39;6&amp;#39; types in enum dmub_notification_type. Not 5. Using smaller<br /> number to create array dmub_callback &amp; dmub_thread_offload has potential to access<br /> item out of array bound. Fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smack: tcp: ipv4, fix incorrect labeling<br /> <br /> Currently, Smack mirrors the label of incoming tcp/ipv4 connections:<br /> when a label &amp;#39;foo&amp;#39; connects to a label &amp;#39;bar&amp;#39; with tcp/ipv4,<br /> &amp;#39;foo&amp;#39; always gets &amp;#39;foo&amp;#39; in returned ipv4 packets. So,<br /> 1) returned packets are incorrectly labeled (&amp;#39;foo&amp;#39; instead of &amp;#39;bar&amp;#39;)<br /> 2) &amp;#39;bar&amp;#39; can write to &amp;#39;foo&amp;#39; without being authorized to write.<br /> <br /> Here is a scenario how to see this:<br /> <br /> * Take two machines, let&amp;#39;s call them C and S,<br /> with active Smack in the default state<br /> (no settings, no rules, no labeled hosts, only builtin labels)<br /> <br /> * At S, add Smack rule &amp;#39;foo bar w&amp;#39;<br /> (labels &amp;#39;foo&amp;#39; and &amp;#39;bar&amp;#39; are instantiated at S at this moment)<br /> <br /> * At S, at label &amp;#39;bar&amp;#39;, launch a program<br /> that listens for incoming tcp/ipv4 connections<br /> <br /> * From C, at label &amp;#39;foo&amp;#39;, connect to the listener at S.<br /> (label &amp;#39;foo&amp;#39; is instantiated at C at this moment)<br /> Connection succeedes and works.<br /> <br /> * Send some data in both directions.<br /> * Collect network traffic of this connection.<br /> <br /> All packets in both directions are labeled with the CIPSO<br /> of the label &amp;#39;foo&amp;#39;. Hence, label &amp;#39;bar&amp;#39; writes to &amp;#39;foo&amp;#39; without<br /> being authorized, and even without ever being known at C.<br /> <br /> If anybody cares: exactly the same happens with DCCP.<br /> <br /> This behavior 1st manifested in release 2.6.29.4 (see Fixes below)<br /> and it looks unintentional. At least, no explanation was provided.<br /> <br /> I changed returned packes label into the &amp;#39;bar&amp;#39;,<br /> to bring it into line with the Smack documentation claims.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsnotify: clear PARENT_WATCHED flags lazily<br /> <br /> In some setups directories can have many (usually negative) dentries.<br /> Hence __fsnotify_update_child_dentry_flags() function can take a<br /> significant amount of time. Since the bulk of this function happens<br /> under inode-&gt;i_lock this causes a significant contention on the lock<br /> when we remove the watch from the directory as the<br /> __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()<br /> races with __fsnotify_update_child_dentry_flags() calls from<br /> __fsnotify_parent() happening on children. This can lead upto softlockup<br /> reports reported by users.<br /> <br /> Fix the problem by calling fsnotify_update_children_dentry_flags() to<br /> set PARENT_WATCHED flags only when parent starts watching children.<br /> <br /> When parent stops watching children, clear false positive PARENT_WATCHED<br /> flags lazily in __fsnotify_parent() for each accessed child.

Substance3D - Stager versions 3.0.3 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Substance3D - Stager versions 3.0.3 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Substance3D - Stager versions 3.0.3 and earlier are affected by a Write-what-where Condition vulnerability that could allow an attacker to execute arbitrary code in the context of the current user. This vulnerability allows an attacker to write a controlled value to an arbitrary memory location, potentially leading to code execution. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Substance3D - Stager versions 3.0.3 and earlier are affected by a Heap-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Substance3D - Stager versions 3.0.3 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Substance3D - Stager versions 3.0.3 and earlier are affected by a Use After Free vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Substance3D - Stager versions 3.0.3 and earlier are affected by a Heap-based Buffer Overflow vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.