Vulnerabilities

In Progress Telerik Reporting versions prior to 2024 Q3 (18.2.24.924), a command injection attack is possible through improper neutralization of hyperlink elements.

In Progress Telerik Reporting versions prior to 2024 Q3 (18.2.24.924), a code execution attack is possible through object injection via an insecure type resolution vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid overflow from uint32_t to uint8_t<br /> <br /> [WHAT &amp; HOW]<br /> dmub_rb_cmd&amp;#39;s ramping_boundary has size of uint8_t and it is assigned<br /> 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.<br /> <br /> This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection<br /> <br /> [Why]<br /> These registers should not be read from driver and triggering the<br /> security violation when DMCUB work times out and diagnostics are<br /> collected blocks Z8 entry.<br /> <br /> [How]<br /> Remove the register read from DCN35.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware<br /> <br /> If the value of max_speed_hz is 0, it may cause a division by zero<br /> error in hisi_calc_effective_speed().<br /> The value of max_speed_hz is provided by firmware.<br /> Firmware is generally considered as a trusted domain. However, as<br /> division by zero errors can cause system failure, for defense measure,<br /> the value of max_speed is validated here. So 0 is regarded as invalid<br /> and an error code is returned.

In Progress® Telerik® Report Server versions prior to 2024 Q3 (10.2.24.806), a credential stuffing attack is possible through improper restriction of excessive login attempts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: iio: frequency: ad9834: Validate frequency parameter value<br /> <br /> In ad9834_write_frequency() clk_get_rate() can return 0. In such case<br /> ad9834_calc_freqreg() call will lead to division by zero. Checking<br /> &amp;#39;if (fout &gt; (clk_freq / 2))&amp;#39; doesn&amp;#39;t protect in case of &amp;#39;fout&amp;#39; is 0.<br /> ad9834_write_frequency() is called from ad9834_write(), where fout is<br /> taken from text buffer, which can contain any value.<br /> <br /> Modify parameters checking.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup<br /> <br /> Definitely condition dma_get_cache_alignment * defined value &gt; 256<br /> during driver initialization is not reason to BUG_ON(). Turn that to<br /> graceful error out with -EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)<br /> <br /> Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0<br /> (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an<br /> inbound PCIe TLP spans more than two internal AXI 128-byte bursts,<br /> the bus may corrupt the packet payload and the corrupt data may<br /> cause associated applications or the processor to hang.<br /> <br /> The workaround for Errata #i2037 is to limit the maximum read<br /> request size and maximum payload size to 128 bytes. Add workaround<br /> for Errata #i2037 here.<br /> <br /> The errata and workaround is applicable only to AM65x SR 1.0 and<br /> later versions of the silicon will have this fixed.<br /> <br /> [1] -&gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()<br /> <br /> If we need to increase the tree depth, allocate a new node, and then<br /> race with another thread that increased the tree depth before us, we&amp;#39;ll<br /> still have a preallocated node that might be used later.<br /> <br /> If we then use that node for a new non-root node, it&amp;#39;ll still have a<br /> pointer to the old root instead of being zeroed - fix this by zeroing it<br /> in the cmpxchg failure path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix state management in error path of log writing function<br /> <br /> After commit a694291a6211 ("nilfs2: separate wait function from<br /> nilfs_segctor_write") was applied, the log writing function<br /> nilfs_segctor_do_construct() was able to issue I/O requests continuously<br /> even if user data blocks were split into multiple logs across segments,<br /> but two potential flaws were introduced in its error handling.<br /> <br /> First, if nilfs_segctor_begin_construction() fails while creating the<br /> second or subsequent logs, the log writing function returns without<br /> calling nilfs_segctor_abort_construction(), so the writeback flag set on<br /> pages/folios will remain uncleared. This causes page cache operations to<br /> hang waiting for the writeback flag. For example,<br /> truncate_inode_pages_final(), which is called via nilfs_evict_inode() when<br /> an inode is evicted from memory, will hang.<br /> <br /> Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. <br /> As a result, if the next log write involves checkpoint creation, that&amp;#39;s<br /> fine, but if a partial log write is performed that does not, inodes with<br /> NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"<br /> list, and their data and b-tree blocks may not be written to the device,<br /> corrupting the block mapping.<br /> <br /> Fix these issues by uniformly calling nilfs_segctor_abort_construction()<br /> on failure of each step in the loop in nilfs_segctor_do_construct(),<br /> having it clean up logs and segment usages according to progress, and<br /> correcting the conditions for calling nilfs_redirty_inodes() to ensure<br /> that the NILFS_I_COLLECTED flag is cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: add bounds checking to ocfs2_xattr_find_entry()<br /> <br /> Add a paranoia check to make sure it doesn&amp;#39;t stray beyond valid memory<br /> region containing ocfs2 xattr entries when scanning for a match. It will<br /> prevent out-of-bound access in case of crafted images.