{"schema_version":"1.7.2","id":"OESA-2024-1622","modified":"2024-05-17T11:08:04Z","published":"2024-05-17T11:08:04Z","upstream":["CVE-2022-48655","CVE-2022-48674","CVE-2023-52477","CVE-2023-52620","CVE-2023-52628","CVE-2023-52631","CVE-2023-52633","CVE-2023-52637","CVE-2023-52639","CVE-2023-52642","CVE-2023-52644","CVE-2023-6270","CVE-2024-26642","CVE-2024-26645","CVE-2024-26665","CVE-2024-26668","CVE-2024-26669","CVE-2024-26671","CVE-2024-26679","CVE-2024-26680","CVE-2024-26684","CVE-2024-26685","CVE-2024-26688","CVE-2024-26689","CVE-2024-26697","CVE-2024-26706","CVE-2024-26707","CVE-2024-26720","CVE-2024-26726","CVE-2024-26733","CVE-2024-26734","CVE-2024-26735","CVE-2024-26739","CVE-2024-26740","CVE-2024-26743","CVE-2024-26744","CVE-2024-26754","CVE-2024-26763","CVE-2024-26776","CVE-2024-26782","CVE-2024-26787","CVE-2024-26791","CVE-2024-26792","CVE-2024-26801","CVE-2024-26804","CVE-2024-26805","CVE-2024-26808","CVE-2024-26809","CVE-2024-26811","CVE-2024-26812","CVE-2024-26814","CVE-2024-26817","CVE-2024-26828","CVE-2024-26829","CVE-2024-26839","CVE-2024-26840","CVE-2024-26843","CVE-2024-26846","CVE-2024-26852","CVE-2024-26855","CVE-2024-26859","CVE-2024-26862","CVE-2024-26863","CVE-2024-26865","CVE-2024-26869","CVE-2024-26870","CVE-2024-26872","CVE-2024-26875","CVE-2024-26878","CVE-2024-26880","CVE-2024-26893","CVE-2024-26895","CVE-2024-26896","CVE-2024-26897","CVE-2024-26917","CVE-2024-26921","CVE-2024-26922"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: arm_scmi: Harden accesses to the reset domains\r\n\r\nAccessing reset domains descriptors by the index upon the SCMI drivers\nrequests through the SCMI reset operations interface can potentially\nlead to out-of-bound violations if the SCMI driver misbehave.\r\n\r\nAdd an internal consistency check before any such domains descriptors\naccesses.(CVE-2022-48655)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nerofs: fix pcluster use-after-free on UP platforms\r\n\r\nDuring stress testing with CONFIG_SMP disabled, KASAN reports as below:\r\n\r\n==================================================================\nBUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30\nRead of size 8 at addr ffff8881094223f8 by task stress/7789\r\n\r\nCPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3\nHardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\nCall Trace:\n \u0026lt;TASK\u0026gt;\n..\n __mutex_lock+0xe5/0xc30\n..\n z_erofs_do_read_page+0x8ce/0x1560\n..\n z_erofs_readahead+0x31c/0x580\n..\nFreed by task 7787\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x20/0x30\n kasan_set_free_info+0x20/0x40\n __kasan_slab_free+0x10c/0x190\n kmem_cache_free+0xed/0x380\n rcu_core+0x3d5/0xc90\n __do_softirq+0x12d/0x389\r\n\r\nLast potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0x97/0xb0\n call_rcu+0x3d/0x3f0\n erofs_shrink_workstation+0x11f/0x210\n erofs_shrink_scan+0xdc/0x170\n shrink_slab.constprop.0+0x296/0x530\n drop_slab+0x1c/0x70\n drop_caches_sysctl_handler+0x70/0x80\n proc_sys_call_handler+0x20a/0x2f0\n vfs_write+0x555/0x6c0\n ksys_write+0xbe/0x160\n do_syscall_64+0x3b/0x90\r\n\r\nThe root cause is that erofs_workgroup_unfreeze() doesn\u0026apos;t reset to\norig_val thus it causes a race that the pcluster reuses unexpectedly\nbefore freeing.\r\n\r\nSince UP platforms are quite rare now, such path becomes unnecessary.\nLet\u0026apos;s drop such specific-designed path directly instead.(CVE-2022-48674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: hub: Guard against accesses to uninitialized BOS descriptors\r\n\r\nMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h\naccess fields inside udev-\u0026gt;bos without checking if it was allocated and\ninitialized. If usb_get_bos_descriptor() fails for whatever\nreason, udev-\u0026gt;bos will be NULL and those accesses will result in a\ncrash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000018\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 \u0026lt;HASH:1f9e 1\u0026gt;\nHardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:hub_port_reset+0x193/0x788\nCode: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 \u0026lt;48\u0026gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9\nRSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310\nRDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840\nRBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0\nCall Trace:\nhub_event+0x73f/0x156e\n? hub_activate+0x5b7/0x68f\nprocess_one_work+0x1a2/0x487\nworker_thread+0x11a/0x288\nkthread+0x13a/0x152\n? process_one_work+0x487/0x487\n? kthread_associate_blkcg+0x70/0x70\nret_from_fork+0x1f/0x30\r\n\r\nFall back to a default behavior if the BOS descriptor isn\u0026apos;t accessible\nand skip all the functionalities that depend on it: LPM support checks,\nSuper Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: disallow timeout for anonymous sets\r\n\r\nNever used from userspace, disallow these parameters.(CVE-2023-52620)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nftables: exthdr: fix 4-byte stack OOB write\r\n\r\nIf priv-\u0026gt;len is a multiple of 4, then dst[len / 4] can write past\nthe destination array which leads to stack corruption.\r\n\r\nThis construct is necessary to clean the remainder of the register\nin case -\u0026gt;len is NOT a multiple of the register size, so make it\nconditional just like nft_payload.c does.\r\n\r\nThe bug was added in 4.1 cycle and then copied/inherited when\ntcp/sctp and ip option support was added.\r\n\r\nBug reported by Zero Day Initiative project (ZDI-CAN-21950,\nZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Fix an NULL dereference bug\r\n\r\nThe issue here is when this is called from ntfs_load_attr_list(). The\n\u0026quot;size\u0026quot; comes from le32_to_cpu(attr-\u0026gt;res.data_size) so it can\u0026apos;t overflow\non a 64bit systems but on 32bit systems the \u0026quot;+ 1023\u0026quot; can overflow and\nthe result is zero. This means that the kmalloc will succeed by\nreturning the ZERO_SIZE_PTR and then the memcpy() will crash with an\nOops on the next line.(CVE-2023-52631)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: time-travel: fix time corruption\r\n\r\nIn \u0026apos;basic\u0026apos; time-travel mode (without =inf-cpu or =ext), we\nstill get timer interrupts. These can happen at arbitrary\npoints in time, i.e. while in timer_read(), which pushes\ntime forward just a little bit. Then, if we happen to get\nthe interrupt after calculating the new time to push to,\nbut before actually finishing that, the interrupt will set\nthe time to a value that\u0026apos;s incompatible with the forward,\nand we\u0026apos;ll crash because time goes backwards when we do the\nforwarding.\r\n\r\nFix this by reading the time_travel_time, calculating the\nadjustment, and doing the adjustment all with interrupts\ndisabled.(CVE-2023-52633)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)\r\n\r\nLock jsk-\u0026gt;sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)\nmodifies jsk-\u0026gt;filters while receiving packets.\r\n\r\nFollowing trace was seen on affected system:\n ==================================================================\n BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n Read of size 4 at addr ffff888012144014 by task j1939/350\r\n\r\n CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n Call Trace:\n print_report+0xd3/0x620\n ? kasan_complete_mode_report_info+0x7d/0x200\n ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n kasan_report+0xc2/0x100\n ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n __asan_load4+0x84/0xb0\n j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]\n j1939_sk_recv+0x20b/0x320 [can_j1939]\n ? __kasan_check_write+0x18/0x20\n ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]\n ? j1939_simple_recv+0x69/0x280 [can_j1939]\n ? j1939_ac_recv+0x5e/0x310 [can_j1939]\n j1939_can_recv+0x43f/0x580 [can_j1939]\n ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]\n ? raw_rcv+0x42/0x3c0 [can_raw]\n ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]\n can_rcv_filter+0x11f/0x350 [can]\n can_receive+0x12f/0x190 [can]\n ? __pfx_can_rcv+0x10/0x10 [can]\n can_rcv+0xdd/0x130 [can]\n ? __pfx_can_rcv+0x10/0x10 [can]\n __netif_receive_skb_one_core+0x13d/0x150\n ? __pfx___netif_receive_skb_one_core+0x10/0x10\n ? __kasan_check_write+0x18/0x20\n ? _raw_spin_lock_irq+0x8c/0xe0\n __netif_receive_skb+0x23/0xb0\n process_backlog+0x107/0x260\n __napi_poll+0x69/0x310\n net_rx_action+0x2a1/0x580\n ? __pfx_net_rx_action+0x10/0x10\n ? __pfx__raw_spin_lock+0x10/0x10\n ? handle_irq_event+0x7d/0xa0\n __do_softirq+0xf3/0x3f8\n do_softirq+0x53/0x80\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0x6e/0x70\n netif_rx+0x16b/0x180\n can_send+0x32b/0x520 [can]\n ? __pfx_can_send+0x10/0x10 [can]\n ? __check_object_size+0x299/0x410\n raw_sendmsg+0x572/0x6d0 [can_raw]\n ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]\n ? apparmor_socket_sendmsg+0x2f/0x40\n ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]\n sock_sendmsg+0xef/0x100\n sock_write_iter+0x162/0x220\n ? __pfx_sock_write_iter+0x10/0x10\n ? __rtnl_unlock+0x47/0x80\n ? security_file_permission+0x54/0x320\n vfs_write+0x6ba/0x750\n ? __pfx_vfs_write+0x10/0x10\n ? __fget_light+0x1ca/0x1f0\n ? __rcu_read_unlock+0x5b/0x280\n ksys_write+0x143/0x170\n ? __pfx_ksys_write+0x10/0x10\n ? __kasan_check_read+0x15/0x20\n ? fpregs_assert_state_consistent+0x62/0x70\n __x64_sys_write+0x47/0x60\n do_syscall_64+0x60/0x90\n ? do_syscall_64+0x6d/0x90\n ? irqentry_exit+0x3f/0x50\n ? exc_page_fault+0x79/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\r\n\r\n Allocated by task 348:\n kasan_save_stack+0x2a/0x50\n kasan_set_track+0x29/0x40\n kasan_save_alloc_info+0x1f/0x30\n __kasan_kmalloc+0xb5/0xc0\n __kmalloc_node_track_caller+0x67/0x160\n j1939_sk_setsockopt+0x284/0x450 [can_j1939]\n __sys_setsockopt+0x15c/0x2f0\n __x64_sys_setsockopt+0x6b/0x80\n do_syscall_64+0x60/0x90\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\r\n\r\n Freed by task 349:\n kasan_save_stack+0x2a/0x50\n kasan_set_track+0x29/0x40\n kasan_save_free_info+0x2f/0x50\n __kasan_slab_free+0x12e/0x1c0\n __kmem_cache_free+0x1b9/0x380\n kfree+0x7a/0x120\n j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]\n __sys_setsockopt+0x15c/0x2f0\n __x64_sys_setsockopt+0x6b/0x80\n do_syscall_64+0x60/0x90\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8(CVE-2023-52637)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: s390: vsie: fix race during shadow creation\r\n\r\nRight now it is possible to see gmap-\u0026gt;private being zero in\nkvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the\nfact that we add gmap-\u0026gt;private == kvm after creation:\r\n\r\nstatic int acquire_gmap_shadow(struct kvm_vcpu *vcpu,\n struct vsie_page *vsie_page)\n{\n[...]\n gmap = gmap_shadow(vcpu-\u0026gt;arch.gmap, asce, edat);\n if (IS_ERR(gmap))\n return PTR_ERR(gmap);\n gmap-\u0026gt;private = vcpu-\u0026gt;kvm;\r\n\r\nLet children inherit the private field of the parent.(CVE-2023-52639)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: rc: bpf attach/detach requires write permission\r\n\r\nNote that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled\r\n\r\nWhen QoS is disabled, the queue priority value will not map to the correct\nieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS\nis disabled to prevent trying to stop/wake a non-existent queue and failing\nto stop/wake the actual queue instantiated.\r\n\r\nLog of issue before change (with kernel parameter qos=0):\n [ +5.112651] ------------[ cut here ]------------\n [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +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\n [ +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\n [ +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)]\n [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS\n [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019\n [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]\n [ +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 \u0026lt;0f\u0026gt; 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00\n [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097\n [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000\n [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900\n [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0\n [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000\n [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40\n [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000\n [ +0.000001] CS: 0010 DS: 0\n---truncated---(CVE-2023-52644)\r\n\r\nA flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.(CVE-2023-6270)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: disallow anonymous set with timeout flag\r\n\r\nAnonymous sets are never used with timeout from userspace, reject this.\nException to this rule is NFT_SET_EVAL to ensure legacy meters still work.(CVE-2024-26642)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Ensure visibility when inserting an element into tracing_map\r\n\r\nRunning the following two commands in parallel on a multi-processor\nAArch64 machine can sporadically produce an unexpected warning about\nduplicate histogram entries:\r\n\r\n $ while true; do\n echo hist:key=id.syscall:val=hitcount \u0026gt; \\\n /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger\n cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist\n sleep 0.001\n done\n $ stress-ng --sysbadaddr $(nproc)\r\n\r\nThe warning looks as follows:\r\n\r\n[ 2911.172474] ------------[ cut here ]------------\n[ 2911.173111] Duplicates detected: 1\n[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408\n[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)\n[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1\n[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01\n[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018\n[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408\n[ 2911.185310] sp : ffff8000a1513900\n[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001\n[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008\n[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180\n[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff\n[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8\n[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731\n[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c\n[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8\n[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000\n[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480\n[ 2911.194259] Call trace:\n[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408\n[ 2911.195220] hist_show+0x124/0x800\n[ 2911.195692] seq_read_iter+0x1d4/0x4e8\n[ 2911.196193] seq_read+0xe8/0x138\n[ 2911.196638] vfs_read+0xc8/0x300\n[ 2911.197078] ksys_read+0x70/0x108\n[ 2911.197534] __arm64_sys_read+0x24/0x38\n[ 2911.198046] invoke_syscall+0x78/0x108\n[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8\n[ 2911.199157] do_el0_svc+0x28/0x40\n[ 2911.199613] el0_svc+0x40/0x178\n[ 2911.200048] el0t_64_sync_handler+0x13c/0x158\n[ 2911.200621] el0t_64_sync+0x1a8/0x1b0\n[ 2911.201115] ---[ end trace 0000000000000000 ]---\r\n\r\nThe problem appears to be caused by CPU reordering of writes issued from\n__tracing_map_insert().\r\n\r\nThe check for the presence of an element with a given key in this\nfunction is:\r\n\r\n val = READ_ONCE(entry-\u0026gt;val);\n if (val \u0026amp;\u0026amp; keys_match(key, val-\u0026gt;key, map-\u0026gt;key_size)) ...\r\n\r\nThe write of a new entry is:\r\n\r\n elt = get_free_elt(map);\n memcpy(elt-\u0026gt;key, key, map-\u0026gt;key_size);\n entry-\u0026gt;val = elt;\r\n\r\nThe \u0026quot;memcpy(elt-\u0026gt;key, key, map-\u0026gt;key_size);\u0026quot; and \u0026quot;entry-\u0026gt;val = elt;\u0026quot;\nstores may become visible in the reversed order on another CPU. This\nsecond CPU might then incorrectly determine that a new key doesn\u0026apos;t match\nan already present val-\u0026gt;key and subse\n---truncated---(CVE-2024-26645)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntunnels: fix out of bounds access when building IPv6 PMTU error\r\n\r\nIf the ICMPv6 error is built from a non-linear skb we get the following\nsplat,\r\n\r\n BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240\n Read of size 4 at addr ffff88811d402c80 by task netperf/820\n CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543\n ...\n kasan_report+0xd8/0x110\n do_csum+0x220/0x240\n csum_partial+0xc/0x20\n skb_tunnel_check_pmtu+0xeb9/0x3280\n vxlan_xmit_one+0x14c2/0x4080\n vxlan_xmit+0xf61/0x5c00\n dev_hard_start_xmit+0xfb/0x510\n __dev_queue_xmit+0x7cd/0x32a0\n br_dev_queue_push_xmit+0x39d/0x6a0\r\n\r\nUse skb_checksum instead of csum_partial who cannot deal with non-linear\nSKBs.(CVE-2024-26665)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_limit: reject configurations that cause integer overflow\r\n\r\nReject bogus configs where internal token counter wraps around.\nThis only occurs with very very large requests, such as 17gbyte/s.\r\n\r\nIts better to reject this rather than having incorrect ratelimit.(CVE-2024-26668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: flower: Fix chain template offload\r\n\r\nWhen a qdisc is deleted from a net device the stack instructs the\nunderlying driver to remove its flow offload callback from the\nassociated filter block using the \u0026apos;FLOW_BLOCK_UNBIND\u0026apos; command. The stack\nthen continues to replay the removal of the filters in the block for\nthis driver by iterating over the chains in the block and invoking the\n\u0026apos;reoffload\u0026apos; operation of the classifier being used. In turn, the\nclassifier in its \u0026apos;reoffload\u0026apos; operation prepares and emits a\n\u0026apos;FLOW_CLS_DESTROY\u0026apos; command for each filter.\r\n\r\nHowever, the stack does not do the same for chain templates and the\nunderlying driver never receives a \u0026apos;FLOW_CLS_TMPLT_DESTROY\u0026apos; command when\na qdisc is deleted. This results in a memory leak [1] which can be\nreproduced using [2].\r\n\r\nFix by introducing a \u0026apos;tmplt_reoffload\u0026apos; operation and have the stack\ninvoke it with the appropriate arguments as part of the replay.\nImplement the operation in the sole classifier that supports chain\ntemplates (flower) by emitting the \u0026apos;FLOW_CLS_TMPLT_{CREATE,DESTROY}\u0026apos;\ncommand based on whether a flow offload callback is being bound to a\nfilter block or being unbound from one.\r\n\r\nAs far as I can tell, the issue happens since cited commit which\nreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()\nin __tcf_block_put(). The order cannot be reversed as the filter block\nis expected to be freed after flushing all the chains.\r\n\r\n[1]\nunreferenced object 0xffff888107e28800 (size 2048):\n comm \u0026quot;tc\u0026quot;, pid 1079, jiffies 4294958525 (age 3074.287s)\n hex dump (first 32 bytes):\n b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[......\n 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................\n backtrace:\n [\u0026lt;ffffffff81c06a68\u0026gt;] __kmem_cache_alloc_node+0x1e8/0x320\n [\u0026lt;ffffffff81ab374e\u0026gt;] __kmalloc+0x4e/0x90\n [\u0026lt;ffffffff832aec6d\u0026gt;] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0\n [\u0026lt;ffffffff832bc195\u0026gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180\n [\u0026lt;ffffffff832b2e1a\u0026gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280\n [\u0026lt;ffffffff83a10613\u0026gt;] tc_setup_cb_call+0x183/0x340\n [\u0026lt;ffffffff83a9f85a\u0026gt;] fl_tmplt_create+0x3da/0x4c0\n [\u0026lt;ffffffff83a22435\u0026gt;] tc_ctl_chain+0xa15/0x1170\n [\u0026lt;ffffffff838a863c\u0026gt;] rtnetlink_rcv_msg+0x3cc/0xed0\n [\u0026lt;ffffffff83ac87f0\u0026gt;] netlink_rcv_skb+0x170/0x440\n [\u0026lt;ffffffff83ac6270\u0026gt;] netlink_unicast+0x540/0x820\n [\u0026lt;ffffffff83ac6e28\u0026gt;] netlink_sendmsg+0x8d8/0xda0\n [\u0026lt;ffffffff83793def\u0026gt;] ____sys_sendmsg+0x30f/0xa80\n [\u0026lt;ffffffff8379d29a\u0026gt;] ___sys_sendmsg+0x13a/0x1e0\n [\u0026lt;ffffffff8379d50c\u0026gt;] __sys_sendmsg+0x11c/0x1f0\n [\u0026lt;ffffffff843b9ce0\u0026gt;] do_syscall_64+0x40/0xe0\nunreferenced object 0xffff88816d2c0400 (size 1024):\n comm \u0026quot;tc\u0026quot;, pid 1079, jiffies 4294958525 (age 3074.287s)\n hex dump (first 32 bytes):\n 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8.....\n 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m....\n backtrace:\n [\u0026lt;ffffffff81c06a68\u0026gt;] __kmem_cache_alloc_node+0x1e8/0x320\n [\u0026lt;ffffffff81ab36c1\u0026gt;] __kmalloc_node+0x51/0x90\n [\u0026lt;ffffffff81a8ed96\u0026gt;] kvmalloc_node+0xa6/0x1f0\n [\u0026lt;ffffffff82827d03\u0026gt;] bucket_table_alloc.isra.0+0x83/0x460\n [\u0026lt;ffffffff82828d2b\u0026gt;] rhashtable_init+0x43b/0x7c0\n [\u0026lt;ffffffff832aed48\u0026gt;] mlxsw_sp_acl_ruleset_get+0x428/0x7a0\n [\u0026lt;ffffffff832bc195\u0026gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180\n [\u0026lt;ffffffff832b2e1a\u0026gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280\n [\u0026lt;ffffffff83a10613\u0026gt;] tc_setup_cb_call+0x183/0x340\n [\u0026lt;ffffffff83a9f85a\u0026gt;] fl_tmplt_create+0x3da/0x4c0\n [\u0026lt;ffffffff83a22435\u0026gt;] tc_ctl_chain+0xa15/0x1170\n [\u0026lt;ffffffff838a863c\u0026gt;] rtnetlink_rcv_msg+0x3cc/0xed0\n [\u0026lt;ffffffff83ac87f0\u0026gt;] netlink_rcv_skb+0x170/0x440\n [\u0026lt;ffffffff83ac6270\u0026gt;] netlink_unicast+0x540/0x820\n [\u0026lt;ffffffff83ac6e28\u0026gt;] netlink_sendmsg+0x8d8/0xda0\n [\u0026lt;ffffffff83793def\u0026gt;] ____sys_sendmsg+0x30f/0xa80\r\n\r\n[2]\n # tc qdisc add dev swp1 clsact\n # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32\n # tc qdisc del dev\n---truncated---(CVE-2024-26669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblk-mq: fix IO hang from sbitmap wakeup race\r\n\r\nIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered\nwith the following blk_mq_get_driver_tag() in case of getting driver\ntag failure.\r\n\r\nThen in __sbitmap_queue_wake_up(), waitqueue_active() may not observe\nthe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime\nblk_mq_mark_tag_wait() can\u0026apos;t get driver tag successfully.\r\n\r\nThis issue can be reproduced by running the following test in loop, and\nfio hang can be observed in \u0026lt; 30min when running it on my test VM\nin laptop.\r\n\r\n\tmodprobe -r scsi_debug\n\tmodprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4\n\tdev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`\n\tfio --filename=/dev/\u0026quot;$dev\u0026quot; --direct=1 --rw=randrw --bs=4k --iodepth=1 \\\n \t\t--runtime=100 --numjobs=40 --time_based --name=test \\\n \t--ioengine=libaio\r\n\r\nFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which\nis just fine in case of running out of tag.(CVE-2024-26671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet: read sk-\u0026gt;sk_family once in inet_recv_error()\r\n\r\ninet_recv_error() is called without holding the socket lock.\r\n\r\nIPv6 socket could mutate to IPv4 with IPV6_ADDRFORM\nsocket option and trigger a KCSAN warning.(CVE-2024-26679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: atlantic: Fix DMA mapping for PTP hwts ring\r\n\r\nFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes\nfor PTP HWTS ring but then generic aq_ring_free() does not take this\ninto account.\nCreate and use a specific function to free HWTS ring to fix this\nissue.\r\n\r\nTrace:\n[ 215.351607] ------------[ cut here ]------------\n[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes]\n[ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360\n...\n[ 215.581176] Call Trace:\n[ 215.583632] \u0026lt;TASK\u0026gt;\n[ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df\n[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df\n[ 215.594497] ? debug_dma_free_coherent+0x196/0x210\n[ 215.599305] ? check_unmap+0xa6f/0x2360\n[ 215.603147] ? __warn+0xca/0x1d0\n[ 215.606391] ? check_unmap+0xa6f/0x2360\n[ 215.610237] ? report_bug+0x1ef/0x370\n[ 215.613921] ? handle_bug+0x3c/0x70\n[ 215.617423] ? exc_invalid_op+0x14/0x50\n[ 215.621269] ? asm_exc_invalid_op+0x16/0x20\n[ 215.625480] ? check_unmap+0xa6f/0x2360\n[ 215.629331] ? mark_lock.part.0+0xca/0xa40\n[ 215.633445] debug_dma_free_coherent+0x196/0x210\n[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10\n[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0\n[ 215.648060] dma_free_attrs+0x6d/0x130\n[ 215.651834] aq_ring_free+0x193/0x290 [atlantic]\n[ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]\n...\n[ 216.127540] ---[ end trace 6467e5964dd2640b ]---\n[ 216.132160] DMA-API: Mapped at:\n[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0\n[ 216.132165] dma_alloc_attrs+0xf5/0x1b0\n[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]\n[ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]\n[ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic](CVE-2024-26680)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: xgmac: fix handling of DPP safety error for DMA channels\r\n\r\nCommit 56e58d6c8a56 (\u0026quot;net: stmmac: Implement Safety Features in\nXGMAC core\u0026quot;) checks and reports safety errors, but leaves the\nData Path Parity Errors for each channel in DMA unhandled at all, lead to\na storm of interrupt.\nFix it by checking and clearing the DMA_DPP_Interrupt_Status register.(CVE-2024-26684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix potential bug in end_buffer_async_write\r\n\r\nAccording to a syzbot report, end_buffer_async_write(), which handles the\ncompletion of block device writes, may detect abnormal condition of the\nbuffer async_write flag and cause a BUG_ON failure when using nilfs2.\r\n\r\nNilfs2 itself does not use end_buffer_async_write(). But, the async_write\nflag is now used as a marker by commit 7f42ec394156 (\u0026quot;nilfs2: fix issue\nwith race condition of competition between segments for dirty blocks\u0026quot;) as\na means of resolving double list insertion of dirty blocks in\nnilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the\nresulting crash.\r\n\r\nThis modification is safe as long as it is used for file data and b-tree\nnode blocks where the page caches are independent. However, it was\nirrelevant and redundant to also introduce async_write for segment summary\nand super root blocks that share buffers with the backing device. This\nled to the possibility that the BUG_ON check in end_buffer_async_write\nwould fail as described above, if independent writebacks of the backing\ndevice occurred in parallel.\r\n\r\nThe use of async_write for segment summary buffers has already been\nremoved in a previous change.\r\n\r\nFix this issue by removing the manipulation of the async_write flag for\nthe remaining super root block buffer.(CVE-2024-26685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super\r\n\r\nWhen configuring a hugetlb filesystem via the fsconfig() syscall, there is\na possible NULL dereference in hugetlbfs_fill_super() caused by assigning\nNULL to ctx-\u0026gt;hstate in hugetlbfs_parse_param() when the requested pagesize\nis non valid.\r\n\r\nE.g: Taking the following steps:\r\n\r\n fd = fsopen(\u0026quot;hugetlbfs\u0026quot;, FSOPEN_CLOEXEC);\n fsconfig(fd, FSCONFIG_SET_STRING, \u0026quot;pagesize\u0026quot;, \u0026quot;1024\u0026quot;, 0);\n fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);\r\n\r\nGiven that the requested \u0026quot;pagesize\u0026quot; is invalid, ctxt-\u0026gt;hstate will be replaced\nwith NULL, losing its previous value, and we will print an error:\r\n\r\n ...\n ...\n case Opt_pagesize:\n ps = memparse(param-\u0026gt;string, \u0026amp;rest);\n ctx-\u0026gt;hstate = h;\n if (!ctx-\u0026gt;hstate) {\n pr_err(\u0026quot;Unsupported page size %lu MB\\n\u0026quot;, ps / SZ_1M);\n return -EINVAL;\n }\n return 0;\n ...\n ...\r\n\r\nThis is a problem because later on, we will dereference ctxt-\u0026gt;hstate in\nhugetlbfs_fill_super()\r\n\r\n ...\n ...\n sb-\u0026gt;s_blocksize = huge_page_size(ctx-\u0026gt;hstate);\n ...\n ...\r\n\r\nCausing below Oops.\r\n\r\nFix this by replacing cxt-\u0026gt;hstate value only when then pagesize is known\nto be valid.\r\n\r\n kernel: hugetlbfs: Unsupported page size 0 MB\n kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028\n kernel: #PF: supervisor read access in kernel mode\n kernel: #PF: error_code(0x0000) - not-present page\n kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0\n kernel: Oops: 0000 [#1] PREEMPT SMP PTI\n kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f\n kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017\n kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0\n kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 \u0026lt;8b\u0026gt; 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28\n kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246\n kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004\n kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000\n kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004\n kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000\n kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400\n kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000\n kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0\n kernel: Call Trace:\n kernel: \u0026lt;TASK\u0026gt;\n kernel: ? __die_body+0x1a/0x60\n kernel: ? page_fault_oops+0x16f/0x4a0\n kernel: ? search_bpf_extables+0x65/0x70\n kernel: ? fixup_exception+0x22/0x310\n kernel: ? exc_page_fault+0x69/0x150\n kernel: ? asm_exc_page_fault+0x22/0x30\n kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10\n kernel: ? hugetlbfs_fill_super+0xb4/0x1a0\n kernel: ? hugetlbfs_fill_super+0x28/0x1a0\n kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10\n kernel: vfs_get_super+0x40/0xa0\n kernel: ? __pfx_bpf_lsm_capable+0x10/0x10\n kernel: vfs_get_tree+0x25/0xd0\n kernel: vfs_cmd_create+0x64/0xe0\n kernel: __x64_sys_fsconfig+0x395/0x410\n kernel: do_syscall_64+0x80/0x160\n kernel: ? syscall_exit_to_user_mode+0x82/0x240\n kernel: ? do_syscall_64+0x8d/0x160\n kernel: ? syscall_exit_to_user_mode+0x82/0x240\n kernel: ? do_syscall_64+0x8d/0x160\n kernel: ? exc_page_fault+0x69/0x150\n kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76\n kernel: RIP: 0033:0x7ffbc0cb87c9\n kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48\n kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af\n kernel: RAX: fffffffffff\n---truncated---(CVE-2024-26688)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nceph: prevent use-after-free in encode_cap_msg()\r\n\r\nIn fs/ceph/caps.c, in encode_cap_msg(), \u0026quot;use after free\u0026quot; error was\ncaught by KASAN at this line - \u0026apos;ceph_buffer_get(arg-\u0026gt;xattr_buf);\u0026apos;. This\nimplies before the refcount could be increment here, it was freed.\r\n\r\nIn same file, in \u0026quot;handle_cap_grant()\u0026quot; refcount is decremented by this\nline - \u0026apos;ceph_buffer_put(ci-\u0026gt;i_xattrs.blob);\u0026apos;. It appears that a race\noccurred and resource was freed by the latter line before the former\nline could increment it.\r\n\r\nencode_cap_msg() is called by __send_cap() and __send_cap() is called by\nceph_check_caps() after calling __prep_cap(). __prep_cap() is where\narg-\u0026gt;xattr_buf is assigned to ci-\u0026gt;i_xattrs.blob. This is the spot where\nthe refcount must be increased to prevent \u0026quot;use after free\u0026quot; error.(CVE-2024-26689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix data corruption in dsync block recovery for small block sizes\r\n\r\nThe helper function nilfs_recovery_copy_block() of\nnilfs_recovery_dsync_blocks(), which recovers data from logs created by\ndata sync writes during a mount after an unclean shutdown, incorrectly\ncalculates the on-page offset when copying repair data to the file\u0026apos;s page\ncache. In environments where the block size is smaller than the page\nsize, this flaw can cause data corruption and leak uninitialized memory\nbytes during the recovery process.\r\n\r\nFix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: Fix random data corruption from exception handler\r\n\r\nThe current exception handler implementation, which assists when accessing\nuser space memory, may exhibit random data corruption if the compiler decides\nto use a different register than the specified register %r29 (defined in\nASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another\nregister, the fault handler will nevertheless store -EFAULT into %r29 and thus\ntrash whatever this register is used for.\nLooking at the assembly I found that this happens sometimes in emulate_ldd().\r\n\r\nTo solve the issue, the easiest solution would be if it somehow is\npossible to tell the fault handler which register is used to hold the error\ncode. Using %0 or %1 in the inline assembly is not posssible as it will show\nup as e.g. %r29 (with the \u0026quot;%r\u0026quot; prefix), which the GNU assembler can not\nconvert to an integer.\r\n\r\nThis patch takes another, better and more flexible approach:\nWe extend the __ex_table (which is out of the execution path) by one 32-word.\nIn this word we tell the compiler to insert the assembler instruction\n\u0026quot;or %r0,%r0,%reg\u0026quot;, where %reg references the register which the compiler\nchoosed for the error return code.\nIn case of an access failure, the fault handler finds the __ex_table entry and\ncan examine the opcode. The used register is encoded in the lowest 5 bits, and\nthe fault handler can then store -EFAULT into this register.\r\n\r\nSince we extend the __ex_table to 3 words we can\u0026apos;t use the BUILDTIME_TABLE_SORT\nconfig option any longer.(CVE-2024-26706)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()\r\n\r\nSyzkaller reported [1] hitting a warning after failing to allocate\nresources for skb in hsr_init_skb(). Since a WARN_ONCE() call will\nnot help much in this case, it might be prudent to switch to\nnetdev_warn_once(). At the very least it will suppress syzkaller\nreports such as [1].\r\n\r\nJust in case, use netdev_warn_once() in send_prp_supervision_frame()\nfor similar reasons.\r\n\r\n[1]\nHSR: Could not send supervision frame\nWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294\nRIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294\n...\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382\n call_timer_fn+0x193/0x590 kernel/time/timer.c:1700\n expire_timers kernel/time/timer.c:1751 [inline]\n __run_timers+0x764/0xb20 kernel/time/timer.c:2022\n run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035\n __do_softirq+0x21a/0x8de kernel/softirq.c:553\n invoke_softirq kernel/softirq.c:427 [inline]\n __irq_exit_rcu kernel/softirq.c:632 [inline]\n irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644\n sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649\n...\r\n\r\nThis issue is also found in older kernels (at least up to 5.10).(CVE-2024-26707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again\r\n\r\n(struct dirty_throttle_control *)-\u0026gt;thresh is an unsigned long, but is\npassed as the u32 divisor argument to div_u64(). On architectures where\nunsigned long is 64 bytes, the argument will be implicitly truncated.\r\n\r\nUse div64_u64() instead of div_u64() so that the value used in the \u0026quot;is\nthis a safe division\u0026quot; check is the same as the divisor.\r\n\r\nAlso, remove redundant cast of the numerator to u64, as that should happen\nimplicitly.\r\n\r\nThis would be difficult to exploit in memcg domain, given the ratio-based\narithmetic domain_drity_limits() uses, but is much easier in global\nwriteback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. \nvm.dirty_bytes=(1\u0026lt;\u0026lt;32)*PAGE_SIZE so that dtc-\u0026gt;thresh == (1\u0026lt;\u0026lt;32)(CVE-2024-26720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t drop extent_map for free space inode on write error\r\n\r\nWhile running the CI for an unrelated change I hit the following panic\nwith generic/648 on btrfs_holes_spacecache.\r\n\r\nassertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385\n------------[ cut here ]------------\nkernel BUG at fs/btrfs/extent_io.c:1385!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1\nRIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n extent_write_cache_pages+0x2ac/0x8f0\n extent_writepages+0x87/0x110\n do_writepages+0xd5/0x1f0\n filemap_fdatawrite_wbc+0x63/0x90\n __filemap_fdatawrite_range+0x5c/0x80\n btrfs_fdatawrite_range+0x1f/0x50\n btrfs_write_out_cache+0x507/0x560\n btrfs_write_dirty_block_groups+0x32a/0x420\n commit_cowonly_roots+0x21b/0x290\n btrfs_commit_transaction+0x813/0x1360\n btrfs_sync_file+0x51a/0x640\n __x64_sys_fdatasync+0x52/0x90\n do_syscall_64+0x9c/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nThis happens because we fail to write out the free space cache in one\ninstance, come back around and attempt to write it again. However on\nthe second pass through we go to call btrfs_get_extent() on the inode to\nget the extent mapping. Because this is a new block group, and with the\nfree space inode we always search the commit root to avoid deadlocking\nwith the tree, we find nothing and return a EXTENT_MAP_HOLE for the\nrequested range.\r\n\r\nThis happens because the first time we try to write the space cache out\nwe hit an error, and on an error we drop the extent mapping. This is\nnormal for normal files, but the free space cache inode is special. We\nalways expect the extent map to be correct. Thus the second time\nthrough we end up with a bogus extent map.\r\n\r\nSince we\u0026apos;re deprecating this feature, the most straightforward way to\nfix this is to simply skip dropping the extent map range for this failed\nrange.\r\n\r\nI shortened the test by using error injection to stress the area to make\nit easier to reproduce. With this patch in place we no longer panic\nwith my error injection test.(CVE-2024-26726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narp: Prevent overflow in arp_req_get().\r\n\r\nsyzkaller reported an overflown write in arp_req_get(). [0]\r\n\r\nWhen ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour\nentry and copies neigh-\u0026gt;ha to struct arpreq.arp_ha.sa_data.\r\n\r\nThe arp_ha here is struct sockaddr, not struct sockaddr_storage, so\nthe sa_data buffer is just 14 bytes.\r\n\r\nIn the splat below, 2 bytes are overflown to the next int field,\narp_flags. We initialise the field just after the memcpy(), so it\u0026apos;s\nnot a problem.\r\n\r\nHowever, when dev-\u0026gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),\narp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)\nin arp_ioctl() before calling arp_req_get().\r\n\r\nTo avoid the overflow, let\u0026apos;s limit the max length of memcpy().\r\n\r\nNote that commit b5f0de6df6dc (\u0026quot;net: dev: Convert sa_data to flexible\narray in struct sockaddr\u0026quot;) just silenced syzkaller.\r\n\r\n[0]:\nmemcpy: detected field-spanning write (size 16) of single field \u0026quot;r-\u0026gt;arp_ha.sa_data\u0026quot; at net/ipv4/arp.c:1128 (size 14)\nWARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nModules linked in:\nCPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014\nRIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nCode: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb \u0026lt;0f\u0026gt; 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6\nRSP: 0018:ffffc900050b7998 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001\nRBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000\nR13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010\nFS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261\n inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981\n sock_do_ioctl+0xdf/0x260 net/socket.c:1204\n sock_ioctl+0x3ef/0x650 net/socket.c:1321\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x64/0xce\nRIP: 0033:0x7f172b262b8d\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d\nRDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003\nRBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000\n \u0026lt;/TASK\u0026gt;(CVE-2024-26733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevlink: fix possible use-after-free and memory leaks in devlink_init()\r\n\r\nThe pernet operations structure for the subsystem must be registered\nbefore registering the generic netlink family.\r\n\r\nMake an unregister in case of unsuccessful registration.(CVE-2024-26734)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix possible use-after-free and null-ptr-deref\r\n\r\nThe pernet operations structure for the subsystem must be registered\nbefore registering the generic netlink family.(CVE-2024-26735)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_mirred: don\u0026apos;t override retval if we already lost the skb\r\n\r\nIf we\u0026apos;re redirecting the skb, and haven\u0026apos;t called tcf_mirred_forward(),\nyet, we need to tell the core to drop the skb by setting the retcode\nto SHOT. If we have called tcf_mirred_forward(), however, the skb\nis out of our hands and returning SHOT will lead to UaF.\r\n\r\nMove the retval override to the error path which actually need it.(CVE-2024-26739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: act_mirred: use the backlog for mirred ingress\r\n\r\nThe test Davide added in commit ca22da2fbd69 (\u0026quot;act_mirred: use the backlog\nfor nested calls to mirred ingress\u0026quot;) hangs our testing VMs every 10 or so\nruns, with the familiar tcp_v4_rcv -\u0026gt; tcp_v4_rcv deadlock reported by\nlockdep.\r\n\r\nThe problem as previously described by Davide (see Link) is that\nif we reverse flow of traffic with the redirect (egress -\u0026gt; ingress)\nwe may reach the same socket which generated the packet. And we may\nstill be holding its socket lock. The common solution to such deadlocks\nis to put the packet in the Rx backlog, rather than run the Rx path\ninline. Do that for all egress -\u0026gt; ingress reversals, not just once\nwe started to nest mirred calls.\r\n\r\nIn the past there was a concern that the backlog indirection will\nlead to loss of error reporting / less accurate stats. But the current\nworkaround does not seem to address the issue.(CVE-2024-26740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/qedr: Fix qedr_create_user_qp error flow\r\n\r\nAvoid the following warning by making sure to free the allocated\nresources in case that qedr_init_user_queue() fail.\r\n\r\n-----------[ cut here ]-----------\nWARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nModules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3\nghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]\nCPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1\nHardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022\nRIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nCode: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 \u0026lt;0f\u0026gt; 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff\nRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286\nRAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016\nRDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600\nRBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80\nR13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? show_trace_log_lvl+0x1c4/0x2df\n? show_trace_log_lvl+0x1c4/0x2df\n? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? __warn+0x81/0x110\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\n? report_bug+0x10a/0x140\n? handle_bug+0x3c/0x70\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]\nib_uverbs_close+0x1f/0xb0 [ib_uverbs]\n__fput+0x94/0x250\ntask_work_run+0x5c/0x90\ndo_exit+0x270/0x4a0\ndo_group_exit+0x2d/0x90\nget_signal+0x87c/0x8c0\narch_do_signal_or_restart+0x25/0x100\n? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]\nexit_to_user_mode_loop+0x9c/0x130\nexit_to_user_mode_prepare+0xb6/0x100\nsyscall_exit_to_user_mode+0x12/0x40\ndo_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? syscall_exit_work+0x103/0x130\n? syscall_exit_to_user_mode+0x22/0x40\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\n? common_interrupt+0x43/0xa0\nentry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x1470abe3ec6b\nCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.\nRSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b\nRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004\nRBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00\nR10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358\nR13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470\n\u0026lt;/TASK\u0026gt;\n--[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srpt: Support specifying the srpt_service_guid parameter\r\n\r\nMake loading ib_srpt with this parameter set work. The current behavior is\nthat setting that parameter while loading the ib_srpt kernel module\ntriggers the following kernel crash:\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCall Trace:\n \u0026lt;TASK\u0026gt;\n parse_one+0x18c/0x1d0\n parse_args+0xe1/0x230\n load_module+0x8de/0xa60\n init_module_from_file+0x8b/0xd0\n idempotent_init_module+0x181/0x240\n __x64_sys_finit_module+0x5a/0xb0\n do_syscall_64+0x5f/0xe0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76(CVE-2024-26744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()\r\n\r\nThe gtp_net_ops pernet operations structure for the subsystem must be\nregistered before registering the generic netlink family.\r\n\r\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\r\n\r\ngeneral protection fault, probably for non-canonical address\n0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\nCPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\nRIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]\nCode: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86\n df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt;\n 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74\nRSP: 0018:ffff888014107220 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000\nFS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x90/0xa0\n ? die_addr+0x50/0xd0\n ? exc_general_protection+0x148/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]\n ? __alloc_skb+0x1dd/0x350\n ? __pfx___alloc_skb+0x10/0x10\n genl_dumpit+0x11d/0x230\n netlink_dump+0x5b9/0xce0\n ? lockdep_hardirqs_on_prepare+0x253/0x430\n ? __pfx_netlink_dump+0x10/0x10\n ? kasan_save_track+0x10/0x40\n ? __kasan_kmalloc+0x9b/0xa0\n ? genl_start+0x675/0x970\n __netlink_dump_start+0x6fc/0x9f0\n genl_family_rcv_msg_dumpit+0x1bb/0x2d0\n ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10\n ? genl_op_from_small+0x2a/0x440\n ? cap_capable+0x1d0/0x240\n ? __pfx_genl_start+0x10/0x10\n ? __pfx_genl_dumpit+0x10/0x10\n ? __pfx_genl_done+0x10/0x10\n ? security_capable+0x9d/0xe0(CVE-2024-26754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm-crypt: don\u0026apos;t modify the data when using authenticated encryption\r\n\r\nIt was said that authenticated encryption could produce invalid tag when\nthe data that is being encrypted is modified [1]. So, fix this problem by\ncopying the data into the clone bio first and then encrypt them inside the\nclone bio.\r\n\r\nThis may reduce performance, but it is needed to prevent the user from\ncorrupting the device by writing data with O_DIRECT and modifying them at\nthe same time.\r\n\r\n[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected\r\n\r\nReturn IRQ_NONE from the interrupt handler when no interrupt was\ndetected. Because an empty interrupt will cause a null pointer error:\r\n\r\n Unable to handle kernel NULL pointer dereference at virtual\n address 0000000000000008\n Call trace:\n complete+0x54/0x100\n hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]\n __handle_irq_event_percpu+0x64/0x1e0\n handle_irq_event+0x7c/0x1cc(CVE-2024-26776)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: fix double-free on socket dismantle\r\n\r\nwhen MPTCP server accepts an incoming connection, it clones its listener\nsocket. However, the pointer to \u0026apos;inet_opt\u0026apos; for the new socket has the same\nvalue as the original one: as a consequence, on program exit it\u0026apos;s possible\nto observe the following splat:\r\n\r\n BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0\n Free of addr ffff888485950880 by task swapper/25/0\r\n\r\n CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609\n Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x32/0x50\n print_report+0xca/0x620\n kasan_report_invalid_free+0x64/0x90\n __kasan_slab_free+0x1aa/0x1f0\n kfree+0xed/0x2e0\n inet_sock_destruct+0x54f/0x8b0\n __sk_destruct+0x48/0x5b0\n rcu_do_batch+0x34e/0xd90\n rcu_core+0x559/0xac0\n __do_softirq+0x183/0x5a4\n irq_exit_rcu+0x12d/0x170\n sysvec_apic_timer_interrupt+0x6b/0x80\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n RIP: 0010:cpuidle_enter_state+0x175/0x300\n Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed \u0026lt;0f\u0026gt; 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b\n RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202\n RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000\n RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588\n RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080\n R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0\n R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80\n cpuidle_enter+0x4a/0xa0\n do_idle+0x310/0x410\n cpu_startup_entry+0x51/0x60\n start_secondary+0x211/0x270\n secondary_startup_64_no_verify+0x184/0x18b\n \u0026lt;/TASK\u0026gt;\r\n\r\n Allocated by task 6853:\n kasan_save_stack+0x1c/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0xa6/0xb0\n __kmalloc+0x1eb/0x450\n cipso_v4_sock_setattr+0x96/0x360\n netlbl_sock_setattr+0x132/0x1f0\n selinux_netlbl_socket_post_create+0x6c/0x110\n selinux_socket_post_create+0x37b/0x7f0\n security_socket_post_create+0x63/0xb0\n __sock_create+0x305/0x450\n __sys_socket_create.part.23+0xbd/0x130\n __sys_socket+0x37/0xb0\n __x64_sys_socket+0x6f/0xb0\n do_syscall_64+0x83/0x160\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\n Freed by task 6858:\n kasan_save_stack+0x1c/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x12c/0x1f0\n kfree+0xed/0x2e0\n inet_sock_destruct+0x54f/0x8b0\n __sk_destruct+0x48/0x5b0\n subflow_ulp_release+0x1f0/0x250\n tcp_cleanup_ulp+0x6e/0x110\n tcp_v4_destroy_sock+0x5a/0x3a0\n inet_csk_destroy_sock+0x135/0x390\n tcp_fin+0x416/0x5c0\n tcp_data_queue+0x1bc8/0x4310\n tcp_rcv_state_process+0x15a3/0x47b0\n tcp_v4_do_rcv+0x2c1/0x990\n tcp_v4_rcv+0x41fb/0x5ed0\n ip_protocol_deliver_rcu+0x6d/0x9f0\n ip_local_deliver_finish+0x278/0x360\n ip_local_deliver+0x182/0x2c0\n ip_rcv+0xb5/0x1c0\n __netif_receive_skb_one_core+0x16e/0x1b0\n process_backlog+0x1e3/0x650\n __napi_poll+0xa6/0x500\n net_rx_action+0x740/0xbb0\n __do_softirq+0x183/0x5a4\r\n\r\n The buggy address belongs to the object at ffff888485950880\n which belongs to the cache kmalloc-64 of size 64\n The buggy address is located 0 bytes inside of\n 64-byte region [ffff888485950880, ffff8884859508c0)\r\n\r\n The buggy address belongs to the physical page:\n page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950\n flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)\n page_type: 0xffffffff()\n raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006\n raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\r\n\r\n Memory state around the buggy address:\n ffff888485950780: fa fb fb\n---truncated---(CVE-2024-26782)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmci: stm32: fix DMA API overlapping mappings warning\r\n\r\nTurning on CONFIG_DMA_API_DEBUG_SG results in the following warning:\r\n\r\nDMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,\noverlapping mappings aren\u0026apos;t supported\nWARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568\nadd_dma_entry+0x234/0x2f4\nModules linked in:\nCPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1\nHardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)\nWorkqueue: events_freezable mmc_rescan\nCall trace:\nadd_dma_entry+0x234/0x2f4\ndebug_dma_map_sg+0x198/0x350\n__dma_map_sg_attrs+0xa0/0x110\ndma_map_sg_attrs+0x10/0x2c\nsdmmc_idma_prep_data+0x80/0xc0\nmmci_prep_data+0x38/0x84\nmmci_start_data+0x108/0x2dc\nmmci_request+0xe4/0x190\n__mmc_start_request+0x68/0x140\nmmc_start_request+0x94/0xc0\nmmc_wait_for_req+0x70/0x100\nmmc_send_tuning+0x108/0x1ac\nsdmmc_execute_tuning+0x14c/0x210\nmmc_execute_tuning+0x48/0xec\nmmc_sd_init_uhs_card.part.0+0x208/0x464\nmmc_sd_init_card+0x318/0x89c\nmmc_attach_sd+0xe4/0x180\nmmc_rescan+0x244/0x320\r\n\r\nDMA API debug brings to light leaking dma-mappings as dma_map_sg and\ndma_unmap_sg are not correctly balanced.\r\n\r\nIf an error occurs in mmci_cmd_irq function, only mmci_dma_error\nfunction is called and as this API is not managed on stm32 variant,\ndma_unmap_sg is never called in this error path.(CVE-2024-26787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: dev-replace: properly validate device names\r\n\r\nThere\u0026apos;s a syzbot report that device name buffers passed to device\nreplace are not properly checked for string termination which could lead\nto a read out of bounds in getname_kernel().\r\n\r\nAdd a helper that validates both source and target device name buffers.\nFor devid as the source initialize the buffer to empty string in case\nsomething tries to read it later.\r\n\r\nThis was originally analyzed and fixed in a different way by Edward Adam\nDavis (see links).(CVE-2024-26791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix double free of anonymous device after snapshot creation failure\r\n\r\nWhen creating a snapshot we may do a double free of an anonymous device\nin case there\u0026apos;s an error committing the transaction. The second free may\nresult in freeing an anonymous device number that was allocated by some\nother subsystem in the kernel or another btrfs filesystem.\r\n\r\nThe steps that lead to this:\r\n\r\n1) At ioctl.c:create_snapshot() we allocate an anonymous device number\n and assign it to pending_snapshot-\u0026gt;anon_dev;\r\n\r\n2) Then we call btrfs_commit_transaction() and end up at\n transaction.c:create_pending_snapshot();\r\n\r\n3) There we call btrfs_get_new_fs_root() and pass it the anonymous device\n number stored in pending_snapshot-\u0026gt;anon_dev;\r\n\r\n4) btrfs_get_new_fs_root() frees that anonymous device number because\n btrfs_lookup_fs_root() returned a root - someone else did a lookup\n of the new root already, which could some task doing backref walking;\r\n\r\n5) After that some error happens in the transaction commit path, and at\n ioctl.c:create_snapshot() we jump to the \u0026apos;fail\u0026apos; label, and after\n that we free again the same anonymous device number, which in the\n meanwhile may have been reallocated somewhere else, because\n pending_snapshot-\u0026gt;anon_dev still has the same value as in step 1.\r\n\r\nRecently syzbot ran into this and reported the following trace:\r\n\r\n ------------[ cut here ]------------\n ida_free called for id=51 which is not allocated.\n WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525\n Modules linked in:\n CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\n RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525\n Code: 10 42 80 3c 28 (...)\n RSP: 0018:ffffc90015a67300 EFLAGS: 00010246\n RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000\n RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000\n RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4\n R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246\n R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246\n FS: 00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346\n create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837\n create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931\n btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404\n create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848\n btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998\n btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044\n __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306\n btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393\n btrfs_ioctl+0xa74/0xd40\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:871 [inline]\n __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n RIP: 0033:0x7fca3e67dda9\n Code: 28 00 00 00 (...)\n RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9\n RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003\n RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658\n \u0026lt;/TASK\u0026gt;\r\n\r\nWhere we get an explicit message where we attempt to free an anonymous\ndevice number that is not currently allocated. It happens in a different\ncode path from the example below, at btrfs_get_root_ref(), so this change\nmay not fix the case triggered by sy\n---truncated---(CVE-2024-26792)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: Avoid potential use-after-free in hci_error_reset\r\n\r\nWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlying\nBT controller is not responding, the GPIO reset mechanism would\nfree the hci_dev and lead to a use-after-free in hci_error_reset.\r\n\r\nHere\u0026apos;s the call trace observed on a ChromeOS device with Intel AX201:\n queue_work_on+0x3e/0x6c\n __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth \u0026lt;HASH:3b4a6\u0026gt;]\n ? init_wait_entry+0x31/0x31\n __hci_cmd_sync+0x16/0x20 [bluetooth \u0026lt;HASH:3b4a 6\u0026gt;]\n hci_error_reset+0x4f/0xa4 [bluetooth \u0026lt;HASH:3b4a 6\u0026gt;]\n process_one_work+0x1d8/0x33f\n worker_thread+0x21b/0x373\n kthread+0x13a/0x152\n ? pr_cont_work+0x54/0x54\n ? kthread_blkcg+0x31/0x31\n ret_from_fork+0x1f/0x30\r\n\r\nThis patch holds the reference count on the hci_dev while processing\na HCI_EV_HARDWARE_ERROR event to avoid potential crash.(CVE-2024-26801)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ip_tunnel: prevent perpetual headroom growth\r\n\r\nsyzkaller triggered following kasan splat:\nBUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170\nRead of size 1 at addr ffff88812fb4000e by task syz-executor183/5191\n[..]\n kasan_report+0xda/0x110 mm/kasan/report.c:588\n __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170\n skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]\n ___skb_get_hash net/core/flow_dissector.c:1791 [inline]\n __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856\n skb_get_hash include/linux/skbuff.h:1556 [inline]\n ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748\n ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564\n __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592\n ...\n ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235\n ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323\n ..\n iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82\n ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831\n ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564\n ...\r\n\r\nThe splat occurs because skb-\u0026gt;data points past skb-\u0026gt;head allocated area.\nThis is because neigh layer does:\n __skb_pull(skb, skb_network_offset(skb));\r\n\r\n... but skb_network_offset() returns a negative offset and __skb_pull()\narg is unsigned. IOW, we skb-\u0026gt;data gets \u0026quot;adjusted\u0026quot; by a huge value.\r\n\r\nThe negative value is returned because skb-\u0026gt;head and skb-\u0026gt;data distance is\nmore than 64k and skb-\u0026gt;network_header (u16) has wrapped around.\r\n\r\nThe bug is in the ip_tunnel infrastructure, which can cause\ndev-\u0026gt;needed_headroom to increment ad infinitum.\r\n\r\nThe syzkaller reproducer consists of packets getting routed via a gre\ntunnel, and route of gre encapsulated packets pointing at another (ipip)\ntunnel. The ipip encapsulation finds gre0 as next output device.\r\n\r\nThis results in the following pattern:\r\n\r\n1). First packet is to be sent out via gre0.\nRoute lookup found an output device, ipip0.\r\n\r\n2).\nip_tunnel_xmit for gre0 bumps gre0-\u0026gt;needed_headroom based on the future\noutput device, rt.dev-\u0026gt;needed_headroom (ipip0).\r\n\r\n3).\nip output / start_xmit moves skb on to ipip0. which runs the same\ncode path again (xmit recursion).\r\n\r\n4).\nRouting step for the post-gre0-encap packet finds gre0 as output device\nto use for ipip0 encapsulated packet.\r\n\r\ntunl0-\u0026gt;needed_headroom is then incremented based on the (already bumped)\ngre0 device headroom.\r\n\r\nThis repeats for every future packet:\r\n\r\ngre0-\u0026gt;needed_headroom gets inflated because previous packets\u0026apos; ipip0 step\nincremented rt-\u0026gt;dev (gre0) headroom, and ipip0 incremented because gre0\nneeded_headroom was increased.\r\n\r\nFor each subsequent packet, gre/ipip0-\u0026gt;needed_headroom grows until\npost-expand-head reallocations result in a skb-\u0026gt;head/data distance of\nmore than 64k.\r\n\r\nOnce that happens, skb-\u0026gt;network_header (u16) wraps around when\npskb_expand_head tries to make sure that skb_network_offset() is unchanged\nafter the headroom expansion/reallocation.\r\n\r\nAfter this skb_network_offset(skb) returns a different (and negative)\nresult post headroom expansion.\r\n\r\nThe next trip to neigh layer (or anything else that would __skb_pull the\nnetwork header) makes skb-\u0026gt;data point to a memory location outside\nskb-\u0026gt;head area.\r\n\r\nv2: Cap the needed_headroom update to an arbitarily chosen upperlimit to\nprevent perpetual increase instead of dropping the headroom increment\ncompletely.(CVE-2024-26804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetlink: Fix kernel-infoleak-after-free in __skb_datagram_iter\r\n\r\nsyzbot reported the following uninit-value access issue [1]:\r\n\r\nnetlink_to_full_skb() creates a new `skb` and puts the `skb-\u0026gt;data`\npassed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data\nsize is specified as `len` and passed to skb_put_data(). This `len`\nis based on `skb-\u0026gt;end` that is not data offset but buffer offset. The\n`skb-\u0026gt;end` contains data and tailroom. Since the tailroom is not\ninitialized when the new `skb` created, KMSAN detects uninitialized\nmemory area when copying the data.\r\n\r\nThis patch resolved this issue by correct the len from `skb-\u0026gt;end` to\n`skb-\u0026gt;len`, which is the actual data offset.\r\n\r\nBUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n copy_to_user_iter lib/iov_iter.c:24 [inline]\n iterate_ubuf include/linux/iov_iter.h:29 [inline]\n iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n iterate_and_advance include/linux/iov_iter.h:271 [inline]\n _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186\n copy_to_iter include/linux/uio.h:197 [inline]\n simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532\n __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420\n skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546\n skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]\n packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482\n sock_recvmsg_nosec net/socket.c:1044 [inline]\n sock_recvmsg net/socket.c:1066 [inline]\n sock_read_iter+0x467/0x580 net/socket.c:1136\n call_read_iter include/linux/fs.h:2014 [inline]\n new_sync_read fs/read_write.c:389 [inline]\n vfs_read+0x8f6/0xe00 fs/read_write.c:470\n ksys_read+0x20f/0x4c0 fs/read_write.c:613\n __do_sys_read fs/read_write.c:623 [inline]\n __se_sys_read fs/read_write.c:621 [inline]\n __x64_sys_read+0x93/0xd0 fs/read_write.c:621\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was stored to memory at:\n skb_put_data include/linux/skbuff.h:2622 [inline]\n netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]\n __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]\n __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325\n netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]\n netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n free_pages_prepare mm/page_alloc.c:1087 [inline]\n free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347\n free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533\n release_pages+0x23d3/0x2410 mm/swap.c:1042\n free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316\n tlb_batch_pages\n---truncated---(CVE-2024-26805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain\r\n\r\nRemove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER\nevent is reported, otherwise a stale reference to netdevice remains in\nthe hook list.(CVE-2024-26808)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_set_pipapo: release elements in clone only from destroy path\r\n\r\nClone already always provides a current view of the lookup table, use it\nto destroy the set, otherwise it is possible to destroy elements twice.\r\n\r\nThis fix requires:\r\n\r\n 212ed75dc5fb (\u0026quot;netfilter: nf_tables: integrate pipapo into commit protocol\u0026quot;)\r\n\r\nwhich came after:\r\n\r\n 9827a0e6e23b (\u0026quot;netfilter: nft_set_pipapo: release elements in clone from abort path\u0026quot;).(CVE-2024-26809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: validate payload size in ipc response\r\n\r\nIf installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc\nresponse to ksmbd kernel server. ksmbd should validate payload size of\nipc response from ksmbd.mountd to avoid memory overrun or\nslab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/pci: Create persistent INTx handler\r\n\r\nA vulnerability exists where the eventfd for INTx signaling can be\ndeconfigured, which unregisters the IRQ handler but still allows\neventfds to be signaled with a NULL context through the SET_IRQS ioctl\nor through unmask irqfd if the device interrupt is pending.\r\n\r\nIdeally this could be solved with some additional locking; the igate\nmutex serializes the ioctl and config space accesses, and the interrupt\nhandler is unregistered relative to the trigger, but the irqfd path\nruns asynchronous to those. The igate mutex cannot be acquired from the\natomic context of the eventfd wake function. Disabling the irqfd\nrelative to the eventfd registration is potentially incompatible with\nexisting userspace.\r\n\r\nAs a result, the solution implemented here moves configuration of the\nINTx interrupt handler to track the lifetime of the INTx context object\nand irq_type configuration, rather than registration of a particular\ntrigger eventfd. Synchronization is added between the ioctl path and\neventfd_signal() wrapper such that the eventfd trigger can be\ndynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfio/fsl-mc: Block calling interrupt handler without trigger\r\n\r\nThe eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is\ninitially NULL and may become NULL if the user sets the trigger\neventfd to -1. The interrupt handler itself is guaranteed that\ntrigger is always valid between request_irq() and free_irq(), but\nthe loopback testing mechanisms to invoke the handler function\nneed to test the trigger. The triggering and setting ioctl paths\nboth make use of igate and are therefore mutually exclusive.\r\n\r\nThe vfio-fsl-mc driver does not make use of irqfds, nor does it\nsupport any sort of masking operations, therefore unlike vfio-pci\nand vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\namdkfd: use calloc instead of kzalloc to avoid integer overflow\r\n\r\nThis uses calloc instead of doing the multiplication which might\noverflow.(CVE-2024-26817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncifs: fix underflow in parse_server_interfaces()\r\n\r\nIn this loop, we step through the buffer and after each item we check\nif the size_left is greater than the minimum size we need. However,\nthe problem is that \u0026quot;bytes_left\u0026quot; is type ssize_t while sizeof() is type\nsize_t. That means that because of type promotion, the comparison is\ndone as an unsigned and if we have negative bytes left the loop\ncontinues instead of ending.(CVE-2024-26828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ir_toy: fix a memleak in irtoy_tx\r\n\r\nWhen irtoy_command fails, buf should be freed since it is allocated by\nirtoy_tx, or there is a memleak.(CVE-2024-26829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/hfi1: Fix a memleak in init_credit_return\r\n\r\nWhen dma_alloc_coherent fails to allocate dd-\u0026gt;cr_base[i].va,\ninit_credit_return should deallocate dd-\u0026gt;cr_base and\ndd-\u0026gt;cr_base[i] that allocated before. Or those resources\nwould be never freed and a memleak is triggered.(CVE-2024-26839)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncachefiles: fix memory leak in cachefiles_add_cache()\r\n\r\nThe following memory leak was reported after unbinding /dev/cachefiles:\r\n\r\n==================================================================\nunreferenced object 0xffff9b674176e3c0 (size 192):\n comm \u0026quot;cachefilesd2\u0026quot;, pid 680, jiffies 4294881224\n hex dump (first 32 bytes):\n 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc ea38a44b):\n [\u0026lt;ffffffff8eb8a1a5\u0026gt;] kmem_cache_alloc+0x2d5/0x370\n [\u0026lt;ffffffff8e917f86\u0026gt;] prepare_creds+0x26/0x2e0\n [\u0026lt;ffffffffc002eeef\u0026gt;] cachefiles_determine_cache_security+0x1f/0x120\n [\u0026lt;ffffffffc00243ec\u0026gt;] cachefiles_add_cache+0x13c/0x3a0\n [\u0026lt;ffffffffc0025216\u0026gt;] cachefiles_daemon_write+0x146/0x1c0\n [\u0026lt;ffffffff8ebc4a3b\u0026gt;] vfs_write+0xcb/0x520\n [\u0026lt;ffffffff8ebc5069\u0026gt;] ksys_write+0x69/0xf0\n [\u0026lt;ffffffff8f6d4662\u0026gt;] do_syscall_64+0x72/0x140\n [\u0026lt;ffffffff8f8000aa\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n==================================================================\r\n\r\nPut the reference count of cache_cred in cachefiles_daemon_unbind() to\nfix the problem. And also put cache_cred in cachefiles_add_cache() error\nbranch to avoid memory leaks.(CVE-2024-26840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi: runtime: Fix potential overflow of soft-reserved region size\r\n\r\nmd_size will have been narrowed if we have \u0026gt;= 4GB worth of pages in a\nsoft-reserved region.(CVE-2024-26843)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-fc: do not wait in vain when unloading module\r\n\r\nThe module exit path has race between deleting all controllers and\nfreeing \u0026apos;left over IDs\u0026apos;. To prevent double free a synchronization\nbetween nvme_delete_ctrl and ida_destroy has been added by the initial\ncommit.\r\n\r\nThere is some logic around trying to prevent from hanging forever in\nwait_for_completion, though it does not handling all cases. E.g.\nblktests is able to reproduce the situation where the module unload\nhangs forever.\r\n\r\nIf we completely rely on the cleanup code executed from the\nnvme_delete_ctrl path, all IDs will be freed eventually. This makes\ncalling ida_destroy unnecessary. We only have to ensure that all\nnvme_delete_ctrl code has been executed before we leave\nnvme_fc_exit_module. This is done by flushing the nvme_delete_wq\nworkqueue.\r\n\r\nWhile at it, remove the unused nvme_fc_wq workqueue too.(CVE-2024-26846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/ipv6: avoid possible UAF in ip6_route_mpath_notify()\r\n\r\nsyzbot found another use-after-free in ip6_route_mpath_notify() [1]\r\n\r\nCommit f7225172f25a (\u0026quot;net/ipv6: prevent use after free in\nip6_route_mpath_notify\u0026quot;) was not able to fix the root cause.\r\n\r\nWe need to defer the fib6_info_release() calls after\nip6_route_mpath_notify(), in the cleanup phase.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0\nRead of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037\r\n\r\nCPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x167/0x540 mm/kasan/report.c:488\n kasan_report+0x142/0x180 mm/kasan/report.c:601\n rt6_fill_node+0x1460/0x1ac0\n inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184\n ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]\n ip6_route_multipath_add net/ipv6/route.c:5404 [inline]\n inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517\n rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f73dd87dda9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9\nRDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005\nRBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 23037:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:372 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389\n kasan_kmalloc include/linux/kasan.h:211 [inline]\n __do_kmalloc_node mm/slub.c:3981 [inline]\n __kmalloc+0x22e/0x490 mm/slub.c:3994\n kmalloc include/linux/slab.h:594 [inline]\n kzalloc include/linux/slab.h:711 [inline]\n fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155\n ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758\n ip6_route_multipath_add net/ipv6/route.c:5298 [inline]\n inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517\n rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\r\n\r\nFreed by task 16:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640\n poison_slab_object+0xa6/0xe0 m\n---truncated---(CVE-2024-26852)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()\r\n\r\nThe function ice_bridge_setlink() may encounter a NULL pointer dereference\nif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently\nin nla_for_each_nested(). To address this issue, add a check to ensure that\nbr_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/bnx2x: Prevent access to a freed page in page_pool\r\n\r\nFix race condition leading to system crash during EEH error handling\r\n\r\nDuring EEH error recovery, the bnx2x driver\u0026apos;s transmit timeout logic\ncould cause a race condition when handling reset tasks. The\nbnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),\nwhich ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()\nSGEs are freed using bnx2x_free_rx_sge_range(). However, this could\noverlap with the EEH driver\u0026apos;s attempt to reset the device using\nbnx2x_io_slot_reset(), which also tries to free SGEs. This race\ncondition can result in system crashes due to accessing freed memory\nlocations in bnx2x_free_rx_sge()\r\n\r\n799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,\n800\t\t\t\tstruct bnx2x_fastpath *fp, u16 index)\n801 {\n802\tstruct sw_rx_page *sw_buf = \u0026amp;fp-\u0026gt;rx_page_ring[index];\n803 struct page *page = sw_buf-\u0026gt;page;\n....\nwhere sw_buf was set to NULL after the call to dma_unmap_page()\nby the preceding thread.\r\n\r\n EEH: Beginning: \u0026apos;slot_reset\u0026apos;\n PCI 0011:01:00.0#10000: EEH: Invoking bnx2x-\u0026gt;slot_reset()\n bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...\n bnx2x 0011:01:00.0: enabling device (0140 -\u0026gt; 0142)\n bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --\u0026gt; driver unload\n Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n BUG: Kernel NULL pointer dereference on read at 0x00000000\n Faulting instruction address: 0xc0080000025065fc\n Oops: Kernel access of bad area, sig: 11 [#1]\n .....\n Call Trace:\n [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)\n [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0\n [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550\n [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60\n [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170\n [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0\n [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64\r\n\r\nTo solve this issue, we need to verify page pool allocations before\nfreeing.(CVE-2024-26859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npacket: annotate data-races around ignore_outgoing\r\n\r\nignore_outgoing is read locklessly from dev_queue_xmit_nit()\nand packet_getsockopt()\r\n\r\nAdd appropriate READ_ONCE()/WRITE_ONCE() annotations.\r\n\r\nsyzbot reported:\r\n\r\nBUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt\r\n\r\nwrite to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:\n packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003\n do_sock_setsockopt net/socket.c:2311 [inline]\n __sys_setsockopt+0x1d8/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nread to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:\n dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248\n xmit_one net/core/dev.c:3527 [inline]\n dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547\n __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108\n batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127\n batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]\n batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]\n batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335\n worker_thread+0x526/0x730 kernel/workqueue.c:3416\n kthread+0x1d1/0x210 kernel/kthread.c:388\n ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\r\n\r\nvalue changed: 0x00 -\u0026gt; 0x01\r\n\r\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet(CVE-2024-26862)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhsr: Fix uninit-value access in hsr_get_node()\r\n\r\nKMSAN reported the following uninit-value access issue [1]:\r\n\r\n=====================================================\nBUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246\n hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246\n fill_frame_info net/hsr/hsr_forward.c:577 [inline]\n hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615\n hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787\n packet_alloc_skb net/packet/af_packet.c:2936 [inline]\n packet_snd net/packet/af_packet.c:3030 [inline]\n packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nCPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\n=====================================================\r\n\r\nIf the packet type ID field in the Ethernet header is either ETH_P_PRP or\nETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()\nreads an invalid value as a sequence number. This causes the above issue.\r\n\r\nThis patch fixes the issue by returning NULL if the Ethernet header is not\nfollowed by an HSR tag.(CVE-2024-26863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrds: tcp: Fix use-after-free of net in reqsk_timer_handler().\r\n\r\nsyzkaller reported a warning of netns tracker [0] followed by KASAN\nsplat [1] and another ref tracker warning [1].\r\n\r\nsyzkaller could not find a repro, but in the log, the only suspicious\nsequence was as follows:\r\n\r\n 18:26:22 executing program 1:\n r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)\n ...\n connect$inet6(r0, \u0026amp;(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)\r\n\r\nThe notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.\r\n\r\nSo, the scenario would be:\r\n\r\n 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in\n rds_tcp_listen_init().\n 2. syz-executor connect()s to it and creates a reqsk.\n 3. syz-executor exit()s immediately.\n 4. netns is dismantled. [0]\n 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]\n 6. listener is freed after RCU grace period. [2]\r\n\r\nBasically, reqsk assumes that the listener guarantees netns safety\nuntil all reqsk timers are expired by holding the listener\u0026apos;s refcount.\nHowever, this was not the case for kernel sockets.\r\n\r\nCommit 740ea3c4a0b2 (\u0026quot;tcp: Clean up kernel listener\u0026apos;s reqsk in\ninet_twsk_purge()\u0026quot;) fixed this issue only for per-netns ehash.\r\n\r\nLet\u0026apos;s apply the same fix for the global ehash.\r\n\r\n[0]:\nref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at\n sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)\n inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)\n __sock_create (net/socket.c:1572)\n rds_tcp_listen_init (net/rds/tcp_listen.c:279)\n rds_tcp_init_net (net/rds/tcp.c:577)\n ops_init (net/core/net_namespace.c:137)\n setup_net (net/core/net_namespace.c:340)\n copy_net_ns (net/core/net_namespace.c:497)\n create_new_namespaces (kernel/nsproxy.c:110)\n unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))\n ksys_unshare (kernel/fork.c:3429)\n __x64_sys_unshare (kernel/fork.c:3496)\n do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)\n...\nWARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\r\n\r\n[1]:\nBUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)\nRead of size 8 at addr ffff88801b370400 by task swapper/0/0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))\n print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)\n kasan_report (mm/kasan/report.c:603)\n inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)\n reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)\n call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)\n __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)\n run_timer_softirq (kernel/time/timer.c:2053)\n __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)\n irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))\n \u0026lt;/IRQ\u0026gt;\r\n\r\nAllocated by task 258 on cpu 0 at 83.612050s:\n kasan_save_stack (mm/kasan/common.c:48)\n kasan_save_track (mm/kasan/common.c:68)\n __kasan_slab_alloc (mm/kasan/common.c:343)\n kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)\n copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)\n create_new_namespaces (kernel/nsproxy.c:110)\n unshare_nsproxy_name\n---truncated---(CVE-2024-26865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to truncate meta inode pages forcely\r\n\r\nBelow race case can cause data corruption:\r\n\r\nThread A\t\t\t\tGC thread\n\t\t\t\t\t- gc_data_segment\n\t\t\t\t\t - ra_data_block\n\t\t\t\t\t - locked meta_inode page\n- f2fs_inplace_write_data\n - invalidate_mapping_pages\n : fail to invalidate meta_inode page\n due to lock failure or dirty|writeback\n status\n - f2fs_submit_page_bio\n : write last dirty data to old blkaddr\n\t\t\t\t\t - move_data_block\n\t\t\t\t\t - load old data from meta_inode page\n\t\t\t\t\t - f2fs_submit_page_write\n\t\t\t\t\t : write old data to new blkaddr\r\n\r\nBecause invalidate_mapping_pages() will skip invalidating page which\nhas unclear status including locked, dirty, writeback and so on, so\nwe need to use truncate_inode_pages_range() instead of\ninvalidate_mapping_pages() to make sure meta_inode page will be dropped.(CVE-2024-26869)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102\r\n\r\nA call to listxattr() with a buffer size = 0 returns the actual\nsize of the buffer needed for a subsequent call. When size \u0026gt; 0,\nnfs4_listxattr() does not return an error because either\ngeneric_listxattr() or nfs4_listxattr_nfs4_label() consumes\nexactly all the bytes then size is 0 when calling\nnfs4_listxattr_nfs4_user() which then triggers the following\nkernel BUG:\r\n\r\n [ 99.403778] kernel BUG at mm/usercopy.c:102!\n [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1\n [ 99.415827] Call trace:\n [ 99.415985] usercopy_abort+0x70/0xa0\n [ 99.416227] __check_heap_object+0x134/0x158\n [ 99.416505] check_heap_object+0x150/0x188\n [ 99.416696] __check_object_size.part.0+0x78/0x168\n [ 99.416886] __check_object_size+0x28/0x40\n [ 99.417078] listxattr+0x8c/0x120\n [ 99.417252] path_listxattr+0x78/0xe0\n [ 99.417476] __arm64_sys_listxattr+0x28/0x40\n [ 99.417723] invoke_syscall+0x78/0x100\n [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0\n [ 99.418186] do_el0_svc+0x24/0x38\n [ 99.418376] el0_svc+0x3c/0x110\n [ 99.418554] el0t_64_sync_handler+0x120/0x130\n [ 99.418788] el0t_64_sync+0x194/0x198\n [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)\r\n\r\nIssue is reproduced when generic_listxattr() returns \u0026apos;system.nfs4_acl\u0026apos;,\nthus calling lisxattr() with size = 16 will trigger the bug.\r\n\r\nAdd check on nfs4_listxattr() to return ERANGE error when it is\ncalled with size \u0026gt; 0 and the return value is greater than size.(CVE-2024-26870)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/srpt: Do not register event handler until srpt device is fully setup\r\n\r\nUpon rare occasions, KASAN reports a use-after-free Write\nin srpt_refresh_port().\r\n\r\nThis seems to be because an event handler is registered before the\nsrpt device is fully setup and a race condition upon error may leave a\npartially setup event handler in place.\r\n\r\nInstead, only register the event handler after srpt device initialization\nis complete.(CVE-2024-26872)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: pvrusb2: fix uaf in pvr2_context_set_notify\r\n\r\n[Syzbot reported]\nBUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35\nRead of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26\r\n\r\nCPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc4/0x620 mm/kasan/report.c:488\n kasan_report+0xda/0x110 mm/kasan/report.c:601\n pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35\n pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]\n pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272\r\n\r\nFreed by task 906:\nkasan_save_stack+0x33/0x50 mm/kasan/common.c:47\nkasan_save_track+0x14/0x30 mm/kasan/common.c:68\nkasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640\npoison_slab_object mm/kasan/common.c:241 [inline]\n__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257\nkasan_slab_free include/linux/kasan.h:184 [inline]\nslab_free_hook mm/slub.c:2121 [inline]\nslab_free mm/slub.c:4299 [inline]\nkfree+0x105/0x340 mm/slub.c:4409\npvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]\npvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158\r\n\r\n[Analyze]\nTask A set disconnect_flag = !0, which resulted in Task B\u0026apos;s condition being met\nand releasing mp, leading to this issue.\r\n\r\n[Fix]\nPlace the disconnect_flag assignment operation after all code in pvr2_context_disconnect()\nto avoid this issue.(CVE-2024-26875)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nquota: Fix potential NULL pointer dereference\r\n\r\nBelow race may cause NULL pointer dereference\r\n\r\nP1\t\t\t\t\tP2\ndquot_free_inode\t\t\tquota_off\n\t\t\t\t\t drop_dquot_ref\n\t\t\t\t\t remove_dquot_ref\n\t\t\t\t\t dquots = i_dquot(inode)\n dquots = i_dquot(inode)\n srcu_read_lock\n dquots[cnt]) != NULL (1)\n\t\t\t\t\t dquots[type] = NULL (2)\n spin_lock(\u0026amp;dquots[cnt]-\u0026gt;dq_dqb_lock) (3)\n ....\r\n\r\nIf dquot_free_inode(or other routines) checks inode\u0026apos;s quota pointers (1)\nbefore quota_off sets it to NULL(2) and use it (3) after that, NULL pointer\ndereference will be triggered.\r\n\r\nSo let\u0026apos;s fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm: call the resume method on internal suspend\r\n\r\nThere is this reported crash when experimenting with the lvm2 testsuite.\nThe list corruption is caused by the fact that the postsuspend and resume\nmethods were not paired correctly; there were two consecutive calls to the\norigin_postsuspend function. The second call attempts to remove the\n\u0026quot;hash_list\u0026quot; entry from a list, while it was already removed by the first\ncall.\r\n\r\nFix __dm_internal_resume so that it calls the preresume and resume\nmethods of the table\u0026apos;s targets.\r\n\r\nIf a preresume method of some target fails, we are in a tricky situation.\nWe can\u0026apos;t return an error because dm_internal_resume isn\u0026apos;t supposed to\nreturn errors. We can\u0026apos;t return success, because then the \u0026quot;resume\u0026quot; and\n\u0026quot;postsuspend\u0026quot; methods would not be paired correctly. So, we set the\nDMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace\ntools, but it won\u0026apos;t cause a kernel crash.\r\n\r\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:56!\ninvalid opcode: 0000 [#1] PREEMPT SMP\nCPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nRIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0\n\u0026lt;snip\u0026gt;\nRSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282\nRAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000\nRDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff\nRBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058\nR10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001\nR13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0\nFS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000\nCS: 0010 DS: 002b ES: 002b CR0: 0000000080050033\nCR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die+0x2d/0x80\n ? do_trap+0xeb/0xf0\n ? __list_del_entry_valid_or_report+0x77/0xc0\n ? do_error_trap+0x60/0x80\n ? __list_del_entry_valid_or_report+0x77/0xc0\n ? exc_invalid_op+0x49/0x60\n ? __list_del_entry_valid_or_report+0x77/0xc0\n ? asm_exc_invalid_op+0x16/0x20\n ? table_deps+0x1b0/0x1b0 [dm_mod]\n ? __list_del_entry_valid_or_report+0x77/0xc0\n origin_postsuspend+0x1a/0x50 [dm_snapshot]\n dm_table_postsuspend_targets+0x34/0x50 [dm_mod]\n dm_suspend+0xd8/0xf0 [dm_mod]\n dev_suspend+0x1f2/0x2f0 [dm_mod]\n ? table_deps+0x1b0/0x1b0 [dm_mod]\n ctl_ioctl+0x300/0x5f0 [dm_mod]\n dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]\n __x64_compat_sys_ioctl+0x104/0x170\n do_syscall_64+0x184/0x1b0\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\nRIP: 0033:0xf7e6aead\n\u0026lt;snip\u0026gt;\n---[ end trace 0000000000000000 ]---(CVE-2024-26880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: arm_scmi: Fix double free in SMC transport cleanup path\r\n\r\nWhen the generic SCMI code tears down a channel, it calls the chan_free\ncallback function, defined by each transport. Since multiple protocols\nmight share the same transport_info member, chan_free() might want to\nclean up the same member multiple times within the given SCMI transport\nimplementation. In this case, it is SMC transport. This will lead to a NULL\npointer dereference at the second time:\r\n\r\n | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16\n | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.\n | arm-scmi firmware:scmi: unable to communicate with SCMI\n | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n | Mem abort info:\n | ESR = 0x0000000096000004\n | EC = 0x25: DABT (current EL), IL = 32 bits\n | SET = 0, FnV = 0\n | EA = 0, S1PTW = 0\n | FSC = 0x04: level 0 translation fault\n | Data abort info:\n | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n | CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000\n | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n | Modules linked in:\n | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793\n | Hardware name: FVP Base RevC (DT)\n | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n | pc : smc_chan_free+0x3c/0x6c\n | lr : smc_chan_free+0x3c/0x6c\n | Call trace:\n | smc_chan_free+0x3c/0x6c\n | idr_for_each+0x68/0xf8\n | scmi_cleanup_channels.isra.0+0x2c/0x58\n | scmi_probe+0x434/0x734\n | platform_probe+0x68/0xd8\n | really_probe+0x110/0x27c\n | __driver_probe_device+0x78/0x12c\n | driver_probe_device+0x3c/0x118\n | __driver_attach+0x74/0x128\n | bus_for_each_dev+0x78/0xe0\n | driver_attach+0x24/0x30\n | bus_add_driver+0xe4/0x1e8\n | driver_register+0x60/0x128\n | __platform_driver_register+0x28/0x34\n | scmi_driver_init+0x84/0xc0\n | do_one_initcall+0x78/0x33c\n | kernel_init_freeable+0x2b8/0x51c\n | kernel_init+0x24/0x130\n | ret_from_fork+0x10/0x20\n | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)\n | ---[ end trace 0000000000000000 ]---\r\n\r\nSimply check for the struct pointer being NULL before trying to access\nits members, to avoid this situation.\r\n\r\nThis was found when a transport doesn\u0026apos;t really work (for instance no SMC\nservice), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces\r\n\r\nwilc_netdev_cleanup currently triggers a KASAN warning, which can be\nobserved on interface registration error path, or simply by\nremoving the module/unbinding device from driver:\r\n\r\necho spi0.1 \u0026gt; /sys/bus/spi/drivers/wilc1000_spi/unbind\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc\nRead of size 4 at addr c54d1ce8 by task sh/86\r\n\r\nCPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117\nHardware name: Atmel SAMA5\n unwind_backtrace from show_stack+0x18/0x1c\n show_stack from dump_stack_lvl+0x34/0x58\n dump_stack_lvl from print_report+0x154/0x500\n print_report from kasan_report+0xac/0xd8\n kasan_report from wilc_netdev_cleanup+0x508/0x5cc\n wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec\n wilc_bus_remove from spi_remove+0x8c/0xac\n spi_remove from device_release_driver_internal+0x434/0x5f8\n device_release_driver_internal from unbind_store+0xbc/0x108\n unbind_store from kernfs_fop_write_iter+0x398/0x584\n kernfs_fop_write_iter from vfs_write+0x728/0xf88\n vfs_write from ksys_write+0x110/0x1e4\n ksys_write from ret_fast_syscall+0x0/0x1c\r\n\r\n[...]\r\n\r\nAllocated by task 1:\n kasan_save_track+0x30/0x5c\n __kasan_kmalloc+0x8c/0x94\n __kmalloc_node+0x1cc/0x3e4\n kvmalloc_node+0x48/0x180\n alloc_netdev_mqs+0x68/0x11dc\n alloc_etherdev_mqs+0x28/0x34\n wilc_netdev_ifc_init+0x34/0x8ec\n wilc_cfg80211_init+0x690/0x910\n wilc_bus_probe+0xe0/0x4a0\n spi_probe+0x158/0x1b0\n really_probe+0x270/0xdf4\n __driver_probe_device+0x1dc/0x580\n driver_probe_device+0x60/0x140\n __driver_attach+0x228/0x5d4\n bus_for_each_dev+0x13c/0x1a8\n bus_add_driver+0x2a0/0x608\n driver_register+0x24c/0x578\n do_one_initcall+0x180/0x310\n kernel_init_freeable+0x424/0x484\n kernel_init+0x20/0x148\n ret_from_fork+0x14/0x28\r\n\r\nFreed by task 86:\n kasan_save_track+0x30/0x5c\n kasan_save_free_info+0x38/0x58\n __kasan_slab_free+0xe4/0x140\n kfree+0xb0/0x238\n device_release+0xc0/0x2a8\n kobject_put+0x1d4/0x46c\n netdev_run_todo+0x8fc/0x11d0\n wilc_netdev_cleanup+0x1e4/0x5cc\n wilc_bus_remove+0xc8/0xec\n spi_remove+0x8c/0xac\n device_release_driver_internal+0x434/0x5f8\n unbind_store+0xbc/0x108\n kernfs_fop_write_iter+0x398/0x584\n vfs_write+0x728/0xf88\n ksys_write+0x110/0x1e4\n ret_fast_syscall+0x0/0x1c\n [...]\r\n\r\nDavid Mosberger-Tan initial investigation [1] showed that this\nuse-after-free is due to netdevice unregistration during vif list\ntraversal. When unregistering a net device, since the needs_free_netdev has\nbeen set to true during registration, the netdevice object is also freed,\nand as a consequence, the corresponding vif object too, since it is\nattached to it as private netdevice data. The next occurrence of the loop\nthen tries to access freed vif pointer to the list to move forward in the\nlist.\r\n\r\nFix this use-after-free thanks to two mechanisms:\n- navigate in the list with list_for_each_entry_safe, which allows to\n safely modify the list as we go through each element. For each element,\n remove it from the list with list_del_rcu\n- make sure to wait for RCU grace period end after each vif removal to make\n sure it is safe to free the corresponding vif too (through\n unregister_netdev)\r\n\r\nSince we are in a RCU \u0026quot;modifier\u0026quot; path (not a \u0026quot;reader\u0026quot; path), and because\nsuch path is expected not to be concurrent to any other modifier (we are\nusing the vif_mutex lock), we do not need to use RCU list API, that\u0026apos;s why\nwe can benefit from list_for_each_entry_safe.\r\n\r\n[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/(CVE-2024-26895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: wfx: fix memory leak when starting AP\r\n\r\nKmemleak reported this error:\r\n\r\n unreferenced object 0xd73d1180 (size 184):\n comm \u0026quot;wpa_supplicant\u0026quot;, pid 1559, jiffies 13006305 (age 964.245s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................\n backtrace:\n [\u0026lt;5ca11420\u0026gt;] kmem_cache_alloc+0x20c/0x5ac\n [\u0026lt;127bdd74\u0026gt;] __alloc_skb+0x144/0x170\n [\u0026lt;fb8a5e38\u0026gt;] __netdev_alloc_skb+0x50/0x180\n [\u0026lt;0f9fa1d5\u0026gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]\n [\u0026lt;7accd02d\u0026gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]\n [\u0026lt;41e25cc3\u0026gt;] wfx_start_ap+0xc8/0x234 [wfx]\n [\u0026lt;93a70356\u0026gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]\n [\u0026lt;a4a661cd\u0026gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]\n [\u0026lt;47bd8b68\u0026gt;] genl_rcv_msg+0x198/0x378\n [\u0026lt;453ef796\u0026gt;] netlink_rcv_skb+0xd0/0x130\n [\u0026lt;6b7c977a\u0026gt;] genl_rcv+0x34/0x44\n [\u0026lt;66b2d04d\u0026gt;] netlink_unicast+0x1b4/0x258\n [\u0026lt;f965b9b6\u0026gt;] netlink_sendmsg+0x1e8/0x428\n [\u0026lt;aadb8231\u0026gt;] ____sys_sendmsg+0x1e0/0x274\n [\u0026lt;d2b5212d\u0026gt;] ___sys_sendmsg+0x80/0xb4\n [\u0026lt;69954f45\u0026gt;] __sys_sendmsg+0x64/0xa8\n unreferenced object 0xce087000 (size 1024):\n comm \u0026quot;wpa_supplicant\u0026quot;, pid 1559, jiffies 13006305 (age 964.246s)\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............\n backtrace:\n [\u0026lt;9a993714\u0026gt;] __kmalloc_track_caller+0x230/0x600\n [\u0026lt;f83ea192\u0026gt;] kmalloc_reserve.constprop.0+0x30/0x74\n [\u0026lt;a2c61343\u0026gt;] __alloc_skb+0xa0/0x170\n [\u0026lt;fb8a5e38\u0026gt;] __netdev_alloc_skb+0x50/0x180\n [\u0026lt;0f9fa1d5\u0026gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]\n [\u0026lt;7accd02d\u0026gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]\n [\u0026lt;41e25cc3\u0026gt;] wfx_start_ap+0xc8/0x234 [wfx]\n [\u0026lt;93a70356\u0026gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]\n [\u0026lt;a4a661cd\u0026gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]\n [\u0026lt;47bd8b68\u0026gt;] genl_rcv_msg+0x198/0x378\n [\u0026lt;453ef796\u0026gt;] netlink_rcv_skb+0xd0/0x130\n [\u0026lt;6b7c977a\u0026gt;] genl_rcv+0x34/0x44\n [\u0026lt;66b2d04d\u0026gt;] netlink_unicast+0x1b4/0x258\n [\u0026lt;f965b9b6\u0026gt;] netlink_sendmsg+0x1e8/0x428\n [\u0026lt;aadb8231\u0026gt;] ____sys_sendmsg+0x1e0/0x274\n [\u0026lt;d2b5212d\u0026gt;] ___sys_sendmsg+0x80/0xb4\r\n\r\nHowever, since the kernel is build optimized, it seems the stack is not\naccurate. It appears the issue is related to wfx_set_mfp_ap(). The issue\nis obvious in this function: memory allocated by ieee80211_beacon_get()\nis never released. Fixing this leak makes kmemleak happy.(CVE-2024-26896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete\r\n\r\nThe ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data\nstructures have been fully initialised by the time it runs. However, because of\nthe order in which things are initialised, this is not guaranteed to be the\ncase, because the device is exposed to the USB subsystem before the ath9k driver\ninitialisation is completed.\r\n\r\nWe already committed a partial fix for this in commit:\n8b3046abc99e (\u0026quot;ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()\u0026quot;)\r\n\r\nHowever, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event\ntasklet, pairing it with an \u0026quot;initialisation complete\u0026quot; bit in the TX struct. It\nseems syzbot managed to trigger the race for one of the other commands as well,\nso let\u0026apos;s just move the existing synchronisation bit to cover the whole\ntasklet (setting it at the end of ath9k_htc_probe_device() instead of inside\nath9k_tx_init()).(CVE-2024-26897)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: Revert \u0026quot;scsi: fcoe: Fix potential deadlock on \u0026amp;fip-\u0026gt;ctlr_lock\u0026quot;\r\n\r\nThis reverts commit 1a1975551943f681772720f639ff42fbaa746212.\r\n\r\nThis commit causes interrupts to be lost for FCoE devices, since it changed\nsping locks from \u0026quot;bh\u0026quot; to \u0026quot;irqsave\u0026quot;.\r\n\r\nInstead, a work queue should be used, and will be addressed in a separate\ncommit.(CVE-2024-26917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet: inet_defrag: prevent sk release while still in use\r\n\r\nip_local_out() and other functions can pass skb-\u0026gt;sk as function argument.\r\n\r\nIf the skb is a fragment and reassembly happens before such function call\nreturns, the sk must not be released.\r\n\r\nThis affects skb fragments reassembled via netfilter or similar\nmodules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.\r\n\r\nEric Dumazet made an initial analysis of this bug. Quoting Eric:\n Calling ip_defrag() in output path is also implying skb_orphan(),\n which is buggy because output path relies on sk not disappearing.\r\n\r\n A relevant old patch about the issue was :\n 8282f27449bf (\u0026quot;inet: frag: Always orphan skbs inside ip_defrag()\u0026quot;)\r\n\r\n [..]\r\n\r\n net/ipv4/ip_output.c depends on skb-\u0026gt;sk being set, and probably to an\n inet socket, not an arbitrary one.\r\n\r\n If we orphan the packet in ipvlan, then downstream things like FQ\n packet scheduler will not work properly.\r\n\r\n We need to change ip_defrag() to only use skb_orphan() when really\n needed, ie whenever frag_list is going to be used.\r\n\r\nEric suggested to stash sk in fragment queue and made an initial patch.\nHowever there is a problem with this:\r\n\r\nIf skb is refragmented again right after, ip_do_fragment() will copy\nhead-\u0026gt;sk to the new fragments, and sets up destructor to sock_wfree.\nIOW, we have no choice but to fix up sk_wmem accouting to reflect the\nfully reassembled skb, else wmem will underflow.\r\n\r\nThis change moves the orphan down into the core, to last possible moment.\nAs ip_defrag_offset is aliased with sk_buff-\u0026gt;sk member, we must move the\noffset into the FRAG_CB, else skb-\u0026gt;sk gets clobbered.\r\n\r\nThis allows to delay the orphaning long enough to learn if the skb has\nto be queued or if the skb is completing the reasm queue.\r\n\r\nIn the former case, things work as before, skb is orphaned. This is\nsafe because skb gets queued/stolen and won\u0026apos;t continue past reasm engine.\r\n\r\nIn the latter case, we will steal the skb-\u0026gt;sk reference, reattach it to\nthe head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: validate the parameters of bo mapping operations more clearly\r\n\r\nVerify the parameters of\namdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.(CVE-2024-26922)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-199.0.0.112.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-devel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","perf-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-199.0.0.112.oe2203sp3.src.rpm"],"x86_64":["kernel-tools-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","perf-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm","kernel-5.10.0-199.0.0.112.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1622"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48655"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48674"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52477"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52620"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52628"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52631"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52633"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52637"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52639"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52644"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-6270"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26645"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26665"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26669"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26671"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26679"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26680"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26684"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26685"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26688"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26689"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26697"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26706"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26707"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26720"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26733"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26734"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26735"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26740"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26743"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26744"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26754"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26763"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26776"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26782"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26787"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26791"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26792"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26801"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26804"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26805"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26808"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26809"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26811"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26812"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26814"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26817"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26828"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26829"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26839"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26840"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26843"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26846"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26852"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26855"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26859"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26862"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26863"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26865"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26869"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26870"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26872"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26875"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26878"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26880"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26893"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26895"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26896"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26897"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26917"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26921"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26922"}],"database_specific":{"severity":"High"}}