Most recent entries from all

ALSA-2024:7000 — Important: kernel security update

2026-10-04T11:32:21.579361+00:00

Affected: AlmaLinux:8: bpftool, AlmaLinux:8: kernel, AlmaLinux:8: kernel-abi-stablelists, AlmaLinux:8: kernel-core, AlmaLinux:8: kernel-cross-headers, AlmaLinux:8: kernel-debug, AlmaLinux:8: kernel-debug-core, AlmaLinux:8: kernel-debug-devel, AlmaLinux:8: kernel-debug-modules, AlmaLinux:8: kernel-debug-modules-extra and 15 more

The kernel packages contain the Linux kernel, the core of any Linux operating system. Security Fix(es):

CVE-2023-6040 CVE-2024-26595 CVE-2024-26600 CVE-2021-46984 CVE-2023-52478 CVE-2023-52476 CVE-2023-52522 CVE-2021-47101 CVE-2021-47097 CVE-2023-52605 CVE-2024-26638 CVE-2024-26645 CVE-2024-26665 CVE-2024-26720 CVE-2024-26717 CVE-2024-26769 CVE-2024-26846 CVE-2024-26894 CVE-2024-26880 CVE-2024-26855 CVE-2024-26923 CVE-2024-26939 CVE-2024-27013 CVE-2024-27042 CVE-2024-35809 CVE-2023-52683 CVE-2024-35884 CVE-2024-35877 CVE-2024-35944 CVE-2024-35989 CVE-2021-47412 CVE-2021-47393 CVE-2021-47386 CVE-2021-47385 CVE-2021-47384 CVE-2021-47383 CVE-2021-47432 CVE-2021-47352 CVE-2021-47338 CVE-2021-47321 CVE-2021-47289 CVE-2021-47287 CVE-2023-52798 CVE-2023-52809 CVE-2023-52817 CVE-2023-52840 CVE-2023-52800 CVE-2021-47441 CVE-2021-47466 CVE-2021-47455 CVE-2021-47497 CVE-2021-47560 CVE-2021-47527 CVE-2024-36883 CVE-2024-36922 CVE-2024-36920 CVE-2024-36902 CVE-2024-36953 CVE-2024-36939 CVE-2024-36919 CVE-2024-36901 CVE-2021-47582 CVE-2021-47609 CVE-2024-38619 CVE-2022-48754 CVE-2022-48760 CVE-2024-38581 CVE-2024-38579 CVE-2024-38570 CVE-2024-38559 CVE-2024-38558 CVE-2024-37356 CVE-2024-39471 CVE-2024-39499 CVE-2024-39501 CVE-2024-39506 CVE-2024-40904 CVE-2024-40911 CVE-2024-40912 CVE-2024-40929 CVE-2024-40931 CVE-2024-40941 CVE-2024-40954 CVE-2024-40958 CVE-2024-40959 CVE-2024-40960 CVE-2024-40972…

bdu:2025-10573

2026-10-04T11:32:21.579494+00:00

bdu:2025-10573

BELL-CVE-2023-52478

2026-10-04T11:32:21.579513+00:00

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

certfr-2024-avi-0242 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'en…

2026-10-04T11:32:21.579534+00:00

certfr-2024-avi-0242

EUVD-2026-344998

2026-10-04T11:32:21.579551+00:00

EUVD-2026-344998

fkie_cve-2023-52478

2026-10-04T11:32:21.579563+00:00

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

HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect

hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself.

hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue.

This opens the following races (note the below code is simplified):

1. Retrieving + printing the protocol (harmless race):

if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; }

We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968:

[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.

Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them:

2. Updating the name to the HIDPP name (harmless race):

if (hidpp->name == hdev->name) { ... hidpp->name = new_name; }

3. Initializing the power_supply class for the battery (problematic!):

hidpp_initialize_battery() {…

GHSA-f7hm-xqp4-h2q8

2026-10-04T11:32:21.579616+00:00

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

HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect

hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself.

This opens the following races (note the below code is simplified):

1. Retrieving + printing the protocol (harmless race):

if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; }

We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968:

[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.

2. Updating the name to the HIDPP name (harmless race):

if (hidpp->name == hdev->name) { ... hidpp->name = new_name; }

3. Initializing the power_supply class for the battery (problematic!):

hidpp_initialize_battery() {…

gsd-2023-52478

2026-10-04T11:32:21.579705+00:00

gsd-2023-52478

ICSA-25-226-15 — Siemens SINEC OS

2026-10-04T11:32:21.579739+00:00

In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scmi: Harden accesses to the reset domains

Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave.

Add an internal consistency check before any such domains descriptors accesses. In the Linux kernel, the following vulnerability has been resolved:

media: lgdt3306a: Add a check against null-pointer-def

The driver should check whether the client provides the platform_data.

The following log reveals it:

[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90 In the Linux kernel, the following vulnerability has been resolved: netfilter:…

RHSA-2024:2394 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update

2026-10-04T11:32:21.580602+00:00

kernel: Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack kernel: ovl: fix warning in ovl_create_real() kernel: memcg does not limit the number of POSIX file locks allowing memory exhaustion kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() kernel: tracing: Fix sleeping function called from invalid context on RT kernel kernel: net: mdio: unexport __init-annotated mdio_bus_init() kernel: arm64: ftrace: consistently handle PLTs. kernel: mm/uffd: fix pte marker when fork() without fork event kernel: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() kernel: tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf() kernel: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead kernel: tee: add overflow check in register_shm_helper() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: PM: hibernate: defer device probing when resuming from hibernation kernel: ext4: don't allow journal inode to have encrypt flag kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: erofs: fix order >= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…

RHSA-2024:7001 — Red Hat Security Advisory: kernel-rt security update

2026-10-04T11:32:21.581173+00:00

kernel: kyber: fix out of bounds access when preempted kernel: Input: elantech - fix stack out of bound access in elantech_change_report_id() kernel: asix: fix uninit-value in asix_mdio_read() kernel: driver core: auxiliary bus: Fix memory leak when driver_register() fail kernel: ACPI: fix NULL pointer dereference kernel: watchdog: Fix possible use-after-free by calling del_timer_sync() kernel: fbmem: Do not delete the mode that is still in use kernel: virtio-net: Add validation for used length kernel: tty: Fix out-of-bound vmalloc access in imageblit kernel: hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: block: don't call rq_qos_ops->done_bio if the bio isn't tracked kernel: lib/generic-radix-tree.c: Don't overflow in peek() kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: ptp: Fix possible memory leak in ptp_clock_register() kernel: mm, slub: fix potential memoryleak in kmem_cache_open() kernel: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells kernel: serial: core: fix transmit-buffer reset and memleak kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: USB: core: Make do_proc_control() and do_proc_bulk() k…

SSA-613116 — SSA-613116: Multiple Vulnerabilities in Third-Party Components in SINEC OS before V3.1

2026-10-04T11:32:21.581364+00:00

firmware: arm_scmi: Harden accesses to the reset domains

Add an internal consistency check before any such domains descriptors accesses. In the Linux kernel, the following vulnerability has been resolved:

media: lgdt3306a: Add a check against null-pointer-def

The driver should check whether the client provides the platform_data.

The following log reveals it:

SUSE-SU-2024:0855-1 — Security update for the Linux Kernel

2026-10-04T11:32:21.582187+00:00

Security update for the Linux Kernel

UBUNTU-CVE-2023-52478

2026-10-04T11:32:21.582230+00:00

Affected: 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 157 more

In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidp…

WID-SEC-W-2024-0511 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service und unspezifische Angriffe

2026-10-04T11:32:21.582468+00:00

Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.