iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()

In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.

staging: iio: frequency: ad9834: Validate frequency parameter value

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

drm/amd/display: Check denominator pbn_div before used

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check denominator pbn_div before used [WHAT & HOW] A denominator cannot be 0, and is checked before used. This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.

drm/amd/display: Assign linear_pitch_alignment even for VM

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Assign linear_pitch_alignment even for VM [Description] Assign linear_pitch_alignment so we don't cause a divide by 0 error in VM environments

nfc: pn533: Add poll mod list filling check

In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Add poll mod list filling check In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

mm/mglru: fix div-by-zero in vmpressure_calc_level()

In the Linux kernel, the following vulnerability has been resolved: mm/mglru: fix div-by-zero in vmpressure_calc_level() evict_folios() uses a second pass to reclaim folios that have gone through page writeback and become clean before it finishes the first pass, since folio_rotate_reclaimable() cannot handle those folios due to the isolation. The second pass tries to avoid potential double counting by deducting scan_control->nr_scanned. However, this can result in underflow of nr_scanned, under a condition where shrink_folio_list() does not increment nr_scanned, i.e., when folio_trylock() fails. The underflow can cause the divisor, i.e., scale=scanned+reclaimed in vmpressure_calc_level(), to become zero, resulting in the following crash: [exception RIP: vmpressure_work_fn+101] process_one_work at ffffffffa3313f2b Since scan_control->nr_scanned has no established semantics, the potential double counting has minimal risks. Therefore, fix the problem by not deducting scan_control->nr_scanned in evict_folios().

Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"

In the Linux kernel, the following vulnerability has been resolved: Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again" Patch series "mm: Avoid possible overflows in dirty throttling". Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details). This patch (of 2): This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78. The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this). Secondly, the div64_u64() is unnecessarily expensive on 32-bit archs. We have div64_ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot.

Wireshark CP2179 divide by zero

Due to a failure in validating the length provided by an attacker-crafted CP2179 packet, Wireshark versions 2.0.0 through 4.0.7 is susceptible to a divide by zero allowing for a denial of service attack.

drm/amd/display: Add check for granularity in dml ceil/floor helpers

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add check for granularity in dml ceil/floor helpers [Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)

scsi: ufs: core: sysfs: Prevent div by zero

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: sysfs: Prevent div by zero Prevent a division by 0 when monitoring is not enabled.

ad7780: fix division by zero in ad7780_write_raw()

In the Linux kernel, the following vulnerability has been resolved: ad7780: fix division by zero in ad7780_write_raw() In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info's write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero.

drm/amd/display: Initialize denominators' default to 1

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Division by zero in urbdrc channel in FreeRDP

FreeRDP is a free remote desktop protocol library and clients. Affected versions of FreeRDP are missing input validation in `urbdrc` channel. A malicious server can trick a FreeRDP based client to crash with division by zero. This issue has been addressed in version 2.9.0. All users are advised to upgrade. Users unable to upgrade should not use the `/usb` redirection switch.

fig2dev float point exception

Floating point exception in fig2dev in version 3.2.9a allows an attacker to availability via local input manipulation via get_slope function.

ftrace: Avoid potential division by zero in function_stat_show()

In the Linux kernel, the following vulnerability has been resolved: ftrace: Avoid potential division by zero in function_stat_show() Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} produce zero and skip stddev computation in that case. For now don't care about rec->counter * rec->counter overflow because rec->time * rec->time overflow will likely happen earlier.

drm/amd/display: Check denominator crb_pipes before used

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check denominator crb_pipes before used [WHAT & HOW] A denominator cannot be 0, and is checked before used. This fixes 2 DIVIDE_BY_ZERO issues reported by Coverity.

ImageMagick CLAHE : Unsigned underflow and division-by-zero lead to OOB pointer arithmetic and process crash (DoS)

ImageMagick is a software suite to create, edit, compose, or convert bitmap images. ImageMagick versions prior to 7.1.2-8 are vulnerable to denial-of-service due to unsigned integer underflow and division-by-zero in the CLAHEImage function. When tile width or height is zero, unsigned underflow occurs in pointer arithmetic, leading to out-of-bounds memory access, and division-by-zero causes immediate crashes. This issue has been patched in version 7.1.2-8.

ImageMagick affected by divide-by-zero in ThumbnailImage via montage -geometry ":" leads to crash

ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to versions 6.9.13-28 and 7.1.2-2, passing a geometry string containing only a colon (":") to montage -geometry leads GetGeometry() to set width/height to 0. Later, ThumbnailImage() divides by these zero dimensions, triggering a crash (SIGFPE/abort), resulting in a denial of service. This issue has been patched in versions 6.9.13-28 and 7.1.2-2.

An issue in redoxOS kernel before commit 5d41cd7c allows a local attacker to cause a denial of service via the `setitimer` syscall

appneta tcpreplay send_packets.c calc_sleep_time divide by zero

A security vulnerability has been detected in appneta tcpreplay 4.5.1. Impacted is the function calc_sleep_time of the file send_packets.c. Such manipulation leads to divide by zero. An attack has to be approached locally. The exploit has been disclosed publicly and may be used. Upgrading to version 4.5.3-beta3 is recommended to address this issue. It is advisable to upgrade the affected component. The vendor confirms in a GitHub issue reply: "Was able to reproduce in 6fcbf03 but NOT 4.5.3-beta3."