https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T23:19:46.977357+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-11918 bdu:2025-11918 2026-10-03T23:19:47.085863+00:00 bdu:2025-11918 https://cve.radiocsirt.org/vuln/bell-cve-2024-57953 BELL-CVE-2024-57953 2026-10-03T23:19:47.085904+00:00

Affected: Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0625 certfr-2025-avi-0625 — De multiples vulnérabilités ont été découvertes dans Ubuntu Ubuntu. Certaines d'entre elles permettent à un attaquant d… 2026-10-03T23:19:47.085934+00:00 certfr-2025-avi-0625 https://cve.radiocsirt.org/vuln/euvd-2026-313931 EUVD-2026-313931 2026-10-03T23:19:47.085951+00:00 EUVD-2026-313931 https://cve.radiocsirt.org/vuln/fkie_cve-2024-57953 fkie_cve-2024-57953 2026-10-03T23:19:47.085962+00:00

In the Linux kernel, the following vulnerability has been resolved:

rtc: tps6594: Fix integer overflow on 32bit systems

The problem is this multiply in tps6594_rtc_set_offset()

tmp = offset * TICKS_PER_HOUR;

The "tmp" variable is an s64 but "offset" is a long in the (-277774)-277774 range. On 32bit systems a long can hold numbers up to approximately two billion. The number of TICKS_PER_HOUR is really large, (32768 * 3600) or roughly a hundred million. When you start multiplying by a hundred million it doesn't take long to overflow the two billion mark.

Probably the safest way to fix this is to change the type of TICKS_PER_HOUR to long long because it's such a large number.

 https://cve.radiocsirt.org/vuln/ghsa-m4w7-955p-fwcr GHSA-m4w7-955p-fwcr 2026-10-03T23:19:47.085995+00:00

In the Linux kernel, the following vulnerability has been resolved:

rtc: tps6594: Fix integer overflow on 32bit systems

The problem is this multiply in tps6594_rtc_set_offset()

tmp = offset * TICKS_PER_HOUR;

The "tmp" variable is an s64 but "offset" is a long in the (-277774)-277774 range. On 32bit systems a long can hold numbers up to approximately two billion. The number of TICKS_PER_HOUR is really large, (32768 * 3600) or roughly a hundred million. When you start multiplying by a hundred million it doesn't take long to overflow the two billion mark.

Probably the safest way to fix this is to change the type of TICKS_PER_HOUR to long long because it's such a large number.

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-57953 UBUNTU-CVE-2024-57953 2026-10-03T23:19:47.086017+00:00

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 106 more

In the Linux kernel, the following vulnerability has been resolved: rtc: tps6594: Fix integer overflow on 32bit systems The problem is this multiply in tps6594_rtc_set_offset() tmp = offset * TICKS_PER_HOUR; The "tmp" variable is an s64 but "offset" is a long in the (-277774)-277774 range. On 32bit systems a long can hold numbers up to approximately two billion. The number of TICKS_PER_HOUR is really large, (32768 * 3600) or roughly a hundred million. When you start multiplying by a hundred million it doesn't take long to overflow the two billion mark. Probably the safest way to fix this is to change the type of TICKS_PER_HOUR to long long because it's such a large number.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0453 WID-SEC-W-2025-0453 — Linux Kernel: Mehrere Schwachstellen 2026-10-03T23:19:47.086184+00:00

Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um die Vertraulichkeit, Integrität und Verfügbarkeit zu gefährden.