CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26861 – wireguard: receive: annotate data-race around receiving_counter.counter
https://notcve.org/view.php?id=CVE-2024-26861
In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wireguard: recibir: anotar carrera de datos alrededor de recibir_counter.counter Syzkaller con KCSAN identificó un problema de carrera de datos al acceder al par de claves->receiving_counter.counter. Utilice las anotaciones READ_ONCE() y WRITE_ONCE() para marcar la carrera de datos como intencional. ERROR: KCSAN: carrera de datos en wg_packet_decrypt_worker/wg_packet_rx_poll escribir en 0xffff888107765888 de 8 bytes por interrupción en la CPU 0: counter_validate drivers/net/wireguard/receive.c:321 [en línea] wg_packet_rx_poll+0x3ac/0xf00 .c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [en línea] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [en línea] _raw_spin_unlock_bh+0x36/0x 40 granos /locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [en línea] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [en línea] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 Process_one_work kernel/workqueue.c:2633 [en línea] ... leído en 0xffff888107765888 de 8 bytes por tarea 3196 en la CPU 1: decrypt_packet drivers/net/wireguard/receive.c:252 [en línea] wg_packet_decrypt_worker+0x220/0x700 drivers/net /wireguard/receive.c:501 Process_one_work kernel/workqueue.c:2633 [en línea] Process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 Workers_thread+0x525/0x730 kernel/workqueue.c:2787 ... • https://git.kernel.org/stable/c/a9e90d9931f3a474f04bab782ccd9d77904941e9 https://git.kernel.org/stable/c/4a7939808afdc57ecaeb72d049e2985321a1e44e https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0 https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6 https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26860 – dm-integrity: fix a memory leak when rechecking the data
https://notcve.org/view.php?id=CVE-2024-26860
In the Linux kernel, the following vulnerability has been resolved: dm-integrity: fix a memory leak when rechecking the data Memory for the "checksums" pointer will leak if the data is rechecked after checksum failure (because the associated kfree won't happen due to 'goto skip_io'). Fix this by freeing the checksums memory before recheck, and just use the "checksum_onstack" memory for storing checksum during recheck. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-integrity: soluciona una pérdida de memoria al volver a verificar los datos. La memoria para el puntero de "sumas de verificación" se perderá si los datos se vuelven a verificar después de una falla en la suma de verificación (porque el kfree asociado no sucederá). debido a 'goto skip_io'). Solucione este problema liberando la memoria de sumas de verificación antes de volver a verificar y simplemente use la memoria "checksum_onstack" para almacenar la suma de verificación durante la nueva verificación. • https://git.kernel.org/stable/c/906414f4596469004632de29126c55751ed82c5e https://git.kernel.org/stable/c/d6824a28b244e8a750952848e4bd2167e1e9a17e https://git.kernel.org/stable/c/eb7b14a6a923c5678573c4d238c781cc83fcbc0f https://git.kernel.org/stable/c/c88f5e553fe38b2ffc4c33d08654e5281b297677 https://git.kernel.org/stable/c/20e21c3c0195d915f33bc7321ee6b362177bf5bf https://git.kernel.org/stable/c/338580a7fb9b0930bb38098007e89cc0fc496bf7 https://git.kernel.org/stable/c/74abc2fe09691f3d836d8a54d599ca71f1e4287b https://git.kernel.org/stable/c/6d35654f03c35c273240d85ec67e3f2c3 •
CVSS: 4.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26859 – net/bnx2x: Prevent access to a freed page in page_pool
https://notcve.org/view.php?id=CVE-2024-26859
In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge() 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp, 800 struct bnx2x_fastpath *fp, u16 index) 801 { 802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index]; 803 struct page *page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? • https://git.kernel.org/stable/c/4cace675d687ebd2d813e90af80ff87ee85202f9 https://git.kernel.org/stable/c/7bcc090c81116c66936a7415f2c6b1483a4bcfd9 https://git.kernel.org/stable/c/4f37d3a7e004bbf560c21441ca9c022168017ec4 https://git.kernel.org/stable/c/8eebff95ce9558be66a36aa7cfb43223f3ab4699 https://git.kernel.org/stable/c/8ffcd3ccdbda0c918c4a0f922ef1c17010f1b598 https://git.kernel.org/stable/c/cf7d8cba639ae792a42c2a137b495eac262ac36c https://git.kernel.org/stable/c/3a9f78b297e08ca8e88ae3ecff1f6fe2766dc5eb https://git.kernel.org/stable/c/c51f8b6930db3f259b8820b589f2459d2 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52644 – wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
https://notcve.org/view.php?id=CVE-2023-52644
In the Linux kernel, the following vulnerability has been resolved: wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: b43: Detener/activar la cola correcta en la ruta DMA Tx cuando QoS está deshabilitado Cuando QoS está deshabilitado, el valor de prioridad de la cola no se asignará a la cola ieee80211 correcta ya que solo hay una cola. Detener/activar la cola 0 cuando la QoS está deshabilitada para evitar intentar detener/activar una cola inexistente y no poder detener/activar la cola real instanciada. Registro del problema antes del cambio (con el parámetro del kernel qos=0): [+5.112651] ------------[ cortar aquí ]------------ [ +0.000005] ADVERTENCIA: CPU: 7 PID: 25513 en net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Módulos vinculados en: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft _chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype superposición ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt _tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel _rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_ buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [+0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common _hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc botón ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fusible retroiluminación firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci cd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [última descarga: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Contaminado: GWO 6.6.7 #1-NixOS [ +0.000 003] Hardware nombre: Apple Inc. • https://git.kernel.org/stable/c/e6f5b934fba8c44c87c551e066aa7ca6fde2939e https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010 https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240 https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08 https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455 https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83 https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96 •
CVSS: 4.1EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26858 – net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map
https://notcve.org/view.php?id=CVE-2024-26858
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map Just simply reordering the functions mlx5e_ptp_metadata_map_put and mlx5e_ptpsq_track_metadata in the mlx5e_txwqe_complete context is not good enough since both the compiler and CPU are free to reorder these two functions. If reordering does occur, the issue that was supposedly fixed by 7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating metadata map") will be seen. This will lead to NULL pointer dereferences in mlx5e_ptpsq_mark_ts_cqes_undelivered in the NAPI polling context due to the tracking list being populated before the metadata map. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: use una barrera de memoria para aplicar PTP WQ. El seguimiento de envío xmit ocurre después de completar metadata_map. • https://git.kernel.org/stable/c/4d510506b46504664eacf8a44a9e8f3e54c137b8 https://git.kernel.org/stable/c/7e3f3ba97e6cc6fce5bf62df2ca06c8e59040167 https://git.kernel.org/stable/c/a9d6c0c5a6bd9ca88e964f8843ea41bc085de866 https://git.kernel.org/stable/c/d1f71615dbb305f14f3b756cce015d70d8667549 https://git.kernel.org/stable/c/936ef086161ab89a7f38f7a0761d6a3063c3277e https://git.kernel.org/stable/c/b7cf07586c40f926063d4d09f7de28ff82f62b2a https://access.redhat.com/security/cve/CVE-2024-26858 https://bugzilla.redhat.com/show_bug.cgi?id=2275735 • CWE-476: NULL Pointer Dereference •