https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 17:36:32 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2023-54079 <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2023-54079 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108 certfr-2026-avi-0108 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0108 https://cve.radiocsirt.org/vuln/euvd-2026-345367 EUVD-2026-345367 https://cve.radiocsirt.org/vuln/euvd-2026-345367 https://cve.radiocsirt.org/vuln/fkie_cve-2023-54079 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>power: supply: bq27xxx: Fix poll_interval handling and races on remove</p> <p>Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item.</p> <p>There are 2 problems with this:</p> <p>1. If the driver is unbound through sysfs, rather then the module being rmmod-ed, this changes poll_interval unexpectedly</p> <p>2. This is racy, after it being set poll_interval could be changed before bq27xxx_battery_update() checks it through /sys/module/bq27xxx_battery/parameters/poll_interval</p> <p>Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0.</p> <p>There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item.</p> <p>Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>power: supply: bq27xxx: Fix poll_interval handling and races on remove</p> <p>Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item.</p> <p>There are 2 problems with this:</p> <p>1. If the driver is unbound through sysfs, rather then the module being rmmod-ed, this changes poll_interval unexpectedly</p> <p>2. This is racy, after it being set poll_interval could be changed before bq27xxx_battery_update() checks it through /sys/module/bq27xxx_battery/parameters/poll_interval</p> <p>Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0.</p> <p>There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item.</p> <p>Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-54079 https://cve.radiocsirt.org/vuln/ghsa-gmfg-4jjj-q47r <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>power: supply: bq27xxx: Fix poll_interval handling and races on remove</p> <p>Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item.</p> <p>There are 2 problems with this:</p> <p>1. If the driver is unbound through sysfs, rather then the module being rmmod-ed, this changes poll_interval unexpectedly</p> <p>2. This is racy, after it being set poll_interval could be changed before bq27xxx_battery_update() checks it through /sys/module/bq27xxx_battery/parameters/poll_interval</p> <p>Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0.</p> <p>There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item.</p> <p>Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>power: supply: bq27xxx: Fix poll_interval handling and races on remove</p> <p>Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item.</p> <p>There are 2 problems with this:</p> <p>1. If the driver is unbound through sysfs, rather then the module being rmmod-ed, this changes poll_interval unexpectedly</p> <p>2. This is racy, after it being set poll_interval could be changed before bq27xxx_battery_update() checks it through /sys/module/bq27xxx_battery/parameters/poll_interval</p> <p>Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0.</p> <p>There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item.</p> <p>Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item.</p> https://cve.radiocsirt.org/vuln/ghsa-gmfg-4jjj-q47r https://cve.radiocsirt.org/vuln/suse-su-2026:0263-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2026:0263-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-54079 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 163 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: power: supply: bq27xxx: Fix poll_interval handling and races on remove Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item. There are 2 problems with this: 1. If the driver is unbound through sysfs, rather then the module being rmmod-ed, this changes poll_interval unexpectedly 2. This is racy, after it being set poll_interval could be changed before bq27xxx_battery_update() checks it through /sys/module/bq27xxx_battery/parameters/poll_interval Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0. There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item. Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 163 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: power: supply: bq27xxx: Fix poll_interval handling and races on remove Before this patch bq27xxx_battery_teardown() was setting poll_interval = 0 to avoid bq27xxx_battery_update() requeuing the delayed_work item. There are 2 problems with this: 1. If the driver is unbound through sysfs, rather then the module being rmmod-ed, this changes poll_interval unexpectedly 2. This is racy, after it being set poll_interval could be changed before bq27xxx_battery_update() checks it through /sys/module/bq27xxx_battery/parameters/poll_interval Fix this by added a removed attribute to struct bq27xxx_device_info and using that instead of setting poll_interval to 0. There also is another poll_interval related race on remove(), writing /sys/module/bq27xxx_battery/parameters/poll_interval will requeue the delayed_work item for all devices on the bq27xxx_battery_devices list and the device being removed was only removed from that list after cancelling the delayed_work item. Fix this by moving the removal from the bq27xxx_battery_devices list to before cancelling the delayed_work item.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-54079 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2929 <p>Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2929