In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix possible buffer overflow\n\nstruct hci_dev_info has a fixed size name[8] field so in the event that\nhdev->name is bigger than that strcpy would attempt to write past its\nsize, so this fixes this problem by switching to use strscpy.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: msft: Fix memory leak\n\nFix leaking buffer allocated to send MSFT_OP_LE_MONITOR_ADVERTISEMENT.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: Fix memory leak\n\nThis checks if CONFIG_DEV_COREDUMP is enabled before attempting to clone\nthe skb and also make sure btmtk_process_coredump frees the skb passed\nfollowing the same logic.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix hashtab overflow check on 32-bit arches\n\nThe hashtab code relies on roundup_pow_of_two() to compute the number of\nhash buckets, and contains an overflow check by checking if the\nresulting value is 0. However, on 32-bit arches, the roundup code itself\ncan overflow by doing a 32-bit left-shift of an unsigned long value,\nwhich is undefined behaviour, so it is not guaranteed to truncate\nneatly. This was triggered by syzbot on the DEVMAP_HASH type, which\ncontains the same check, copied from the hashtab code. So apply the same\nfix to hashtab, by moving the overflow check to before the roundup.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()\n\nApply the same fix than ones found in :\n\n8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")\n1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")\n\nWe have to save skb->network_header in a temporary variable\nin order to be able to recompute the network_header pointer\nafter a pskb_inet_may_pull() call.\n\npskb_inet_may_pull() makes sure the needed headers are in skb->head.\n\nsyzbot reported:\nBUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409\n __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]\n ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409\n __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389\n ipgre_rcv net/ipv4/ip_gre.c:411 [inline]\n gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447\n gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163\n ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205\n ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254\n dst_input include/net/dst.h:461 [inline]\n ip_rcv_finish net/ipv4/ip_input.c:449 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core net/core/dev.c:5534 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648\n netif_receive_skb_internal net/core/dev.c:5734 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5793\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556\n tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055\n call_write_iter include/linux/fs.h:2087 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb6b/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590\n alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133\n alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204\n skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909\n tun_build_skb drivers/net/tun.c:1686 [inline]\n tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826\n tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055\n call_write_iter include/linux/fs.h:2087 [inline]\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0xb6b/0x1520 fs/read_write.c:590\n ksys_write+0x20f/0x4c0 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x93/0xd0 fs/read_write.c:652\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when 1588 is received on HIP08 devices\n\nThe HIP08 devices does not register the ptp devices, so the\nhdev->ptp is NULL, but the hardware can receive 1588 messages,\nand set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the\naccess of hdev->ptp->flags will cause a kernel crash:\n\n[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n...\n[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]\n[ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]\n[ 5889.279101] sp : ffff800012c3bc50\n[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040\n[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500\n[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000\n[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000\n[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080\n[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000\n[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000\n[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000\n[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df\n[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000\n[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d\n[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480\n[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000\n[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000\n[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080\n[ 5889.378857] Call trace:\n[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]\n[ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]\n[ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]\n[ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]\n[ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]\n[ 5889.411084] napi_poll+0xcc/0x264\n[ 5889.415329] net_rx_action+0xd4/0x21c\n[ 5889.419911] __do_softirq+0x130/0x358\n[ 5889.424484] irq_exit+0x134/0x154\n[ 5889.428700] __handle_domain_irq+0x88/0xf0\n[ 5889.433684] gic_handle_irq+0x78/0x2c0\n[ 5889.438319] el1_irq+0xb8/0x140\n[ 5889.442354] arch_cpu_idle+0x18/0x40\n[ 5889.446816] default_idle_call+0x5c/0x1c0\n[ 5889.451714] cpuidle_idle_call+0x174/0x1b0\n[ 5889.456692] do_idle+0xc8/0x160\n[ 5889.460717] cpu_startup_entry+0x30/0xfc\n[ 5889.465523] secondary_start_kernel+0x158/0x1ec\n[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)\n[ 5889.477950] SMP: stopping secondary CPUs\n[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95\n[ 5890.522951] Starting crashdump kernel...

In the Linux kernel, the following vulnerability has been resolved:\n\nclk: meson: Add missing clocks to axg_clk_regmaps\n\nSome clocks were missing from axg_clk_regmaps, which caused kernel panic\nduring cat /sys/kernel/debug/clk/clk_summary\n\n[ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc\n...\n[ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 57.436900] pc : regmap_read+0x1c/0x88\n[ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0\n[ 57.445611] sp : ffff800082f1b690\n[ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70\n[ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000\n[ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000\n[ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff\n[ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000\n[ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100\n[ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24\n[ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710\n[ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000\n[ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000\n[ 57.519615] Call trace:\n[ 57.522030] regmap_read+0x1c/0x88\n[ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0\n[ 57.530050] clk_core_is_enabled+0x44/0x120\n[ 57.534190] clk_summary_show_subtree+0x154/0x2f0\n[ 57.538847] clk_summary_show_subtree+0x220/0x2f0\n[ 57.543505] clk_summary_show_subtree+0x220/0x2f0\n[ 57.548162] clk_summary_show_subtree+0x220/0x2f0\n[ 57.552820] clk_summary_show_subtree+0x220/0x2f0\n[ 57.557477] clk_summary_show_subtree+0x220/0x2f0\n[ 57.562135] clk_summary_show_subtree+0x220/0x2f0\n[ 57.566792] clk_summary_show_subtree+0x220/0x2f0\n[ 57.571450] clk_summary_show+0x84/0xb8\n[ 57.575245] seq_read_iter+0x1bc/0x4b8\n[ 57.578954] seq_read+0x8c/0xd0\n[ 57.582059] full_proxy_read+0x68/0xc8\n[ 57.585767] vfs_read+0xb0/0x268\n[ 57.588959] ksys_read+0x70/0x108\n[ 57.592236] __arm64_sys_read+0x24/0x38\n[ 57.596031] invoke_syscall+0x50/0x128\n[ 57.599740] el0_svc_common.constprop.0+0x48/0xf8\n[ 57.604397] do_el0_svc+0x28/0x40\n[ 57.607675] el0_svc+0x34/0xb8\n[ 57.610694] el0t_64_sync_handler+0x13c/0x158\n[ 57.615006] el0t_64_sync+0x190/0x198\n[ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)\n[ 57.624668] ---[ end trace 0000000000000000 ]---\n\n[jbrunet: add missing Fixes tag]

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: pvrusb2: fix uaf in pvr2_context_set_notify\n\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\n\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 <TASK>\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\n\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\n\n[Analyze]\nTask A set disconnect_flag = !0, which resulted in Task B's condition being met\nand releasing mp, leading to this issue.\n\n[Fix]\nPlace the disconnect_flag assignment operation after all code in pvr2_context_disconnect()\nto avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Fix a deadlock issue related to automatic dump\n\nIf we issue a disabling PHY command, the device attached with it will go\noffline, if a 2 bit ECC error occurs at the same time, a hung task may be\nfound:\n\n[ 4613.652388] INFO: task kworker/u256:0:165233 blocked for more than 120 seconds.\n[ 4613.666297] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n[ 4613.674809] task:kworker/u256:0 state:D stack: 0 pid:165233 ppid: 2 flags:0x00000208\n[ 4613.683959] Workqueue: 0000:74:02.0_disco_q sas_revalidate_domain [libsas]\n[ 4613.691518] Call trace:\n[ 4613.694678] __switch_to+0xf8/0x17c\n[ 4613.698872] __schedule+0x660/0xee0\n[ 4613.703063] schedule+0xac/0x240\n[ 4613.706994] schedule_timeout+0x500/0x610\n[ 4613.711705] __down+0x128/0x36c\n[ 4613.715548] down+0x240/0x2d0\n[ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc/0x260 [hisi_sas_main]\n[ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas]\n[ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas]\n[ 4613.739504] hisi_sas_internal_task_abort_dev.isra.0+0xbc/0x1b0 [hisi_sas_main]\n[ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main]\n[ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas]\n[ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas]\n[ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas]\n[ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas]\n[ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas]\n[ 4613.784716] process_one_work+0x248/0x950\n[ 4613.789424] worker_thread+0x318/0x934\n[ 4613.793878] kthread+0x190/0x200\n[ 4613.797810] ret_from_fork+0x10/0x18\n[ 4613.802121] INFO: task kworker/u256:4:316722 blocked for more than 120 seconds.\n[ 4613.816026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n[ 4613.824538] task:kworker/u256:4 state:D stack: 0 pid:316722 ppid: 2 flags:0x00000208\n[ 4613.833670] Workqueue: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main]\n[ 4613.841491] Call trace:\n[ 4613.844647] __switch_to+0xf8/0x17c\n[ 4613.848852] __schedule+0x660/0xee0\n[ 4613.853052] schedule+0xac/0x240\n[ 4613.856984] schedule_timeout+0x500/0x610\n[ 4613.861695] __down+0x128/0x36c\n[ 4613.865542] down+0x240/0x2d0\n[ 4613.869216] hisi_sas_controller_prereset+0x58/0x1fc [hisi_sas_main]\n[ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main]\n[ 4613.883019] process_one_work+0x248/0x950\n[ 4613.887732] worker_thread+0x318/0x934\n[ 4613.892204] kthread+0x190/0x200\n[ 4613.896118] ret_from_fork+0x10/0x18\n[ 4613.900423] INFO: task kworker/u256:1:348985 blocked for more than 121 seconds.\n[ 4613.914341] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n[ 4613.922852] task:kworker/u256:1 state:D stack: 0 pid:348985 ppid: 2 flags:0x00000208\n[ 4613.931984] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas]\n[ 4613.939549] Call trace:\n[ 4613.942702] __switch_to+0xf8/0x17c\n[ 4613.946892] __schedule+0x660/0xee0\n[ 4613.951083] schedule+0xac/0x240\n[ 4613.955015] schedule_timeout+0x500/0x610\n[ 4613.959725] wait_for_common+0x200/0x610\n[ 4613.964349] wait_for_completion+0x3c/0x5c\n[ 4613.969146] flush_workqueue+0x198/0x790\n[ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas]\n[ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas]\n[ 4613.985708] process_one_work+0x248/0x950\n[ 4613.990420] worker_thread+0x318/0x934\n[ 4613.994868] kthread+0x190/0x200\n[ 4613.998800] ret_from_fork+0x10/0x18\n\nThis is because when the device goes offline, we obtain the hisi_hba\nsemaphore and send the ABORT_DEV command to the device. However, the\ninternal abort timed out due to the 2 bit ECC error and triggers automatic\ndump. In addition, since the hisi_hba semaphore has been obtained, the dump\ncannot be executed and the controller cannot be reset.\n\nTherefore, the deadlocks occur on the following circular dependencies:\nhisi_sas_dev_gone() -> down() -> hisi_sas_internal_task_abort_dev() -> ...\n-> hisi_sas_internal_abort_timeout() -> down().\n\nThe deadlock is triggered only when the timeout occurs during device goes\noffline. To fix this issue, use .rst_ha_timeout to distinguish the scenario\nwhere a device goes offline from other scenarios.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix NULL pointer dereference in f2fs_submit_page_write()\n\nBUG: kernel NULL pointer dereference, address: 0000000000000014\nRIP: 0010:f2fs_submit_page_write+0x6cf/0x780 [f2fs]\nCall Trace:\n<TASK>\n? show_regs+0x6e/0x80\n? __die+0x29/0x70\n? page_fault_oops+0x154/0x4a0\n? prb_read_valid+0x20/0x30\n? __irq_work_queue_local+0x39/0xd0\n? irq_work_queue+0x36/0x70\n? do_user_addr_fault+0x314/0x6c0\n? exc_page_fault+0x7d/0x190\n? asm_exc_page_fault+0x2b/0x30\n? f2fs_submit_page_write+0x6cf/0x780 [f2fs]\n? f2fs_submit_page_write+0x736/0x780 [f2fs]\ndo_write_page+0x50/0x170 [f2fs]\nf2fs_outplace_write_data+0x61/0xb0 [f2fs]\nf2fs_do_write_data_page+0x3f8/0x660 [f2fs]\nf2fs_write_single_data_page+0x5bb/0x7a0 [f2fs]\nf2fs_write_cache_pages+0x3da/0xbe0 [f2fs]\n...\nIt is possible that other threads have added this fio to io->bio\nand submitted the io->bio before entering f2fs_submit_page_write().\nAt this point io->bio = NULL.\nIf is_end_zone_blkaddr(sbi, fio->new_blkaddr) of this fio is true,\nthen an NULL pointer dereference error occurs at bio_get(io->bio).\nThe original code for determining zone end was after "out:",\nwhich would have missed some fio who is zone end. I've moved\n this code before "skip:" to make sure it's done for each fio.

In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: fix panic when nfs4_ff_layout_prepare_ds() fails\n\nWe've been seeing the following panic in production\n\nBUG: kernel NULL pointer dereference, address: 0000000000000065\nPGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0\nRIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]\nCall Trace:\n <TASK>\n ? __die+0x78/0xc0\n ? page_fault_oops+0x286/0x380\n ? __rpc_execute+0x2c3/0x470 [sunrpc]\n ? rpc_new_task+0x42/0x1c0 [sunrpc]\n ? exc_page_fault+0x5d/0x110\n ? asm_exc_page_fault+0x22/0x30\n ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]\n ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]\n ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]\n pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]\n pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]\n ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]\n nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]\n ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]\n __nfs_pageio_add_request+0x154/0x6c0 [nfs]\n nfs_pageio_add_request+0x26b/0x380 [nfs]\n nfs_do_writepage+0x111/0x1e0 [nfs]\n nfs_writepages_callback+0xf/0x30 [nfs]\n write_cache_pages+0x17f/0x380\n ? nfs_pageio_init_write+0x50/0x50 [nfs]\n ? nfs_writepages+0x6d/0x210 [nfs]\n ? nfs_writepages+0x6d/0x210 [nfs]\n nfs_writepages+0x125/0x210 [nfs]\n do_writepages+0x67/0x220\n ? generic_perform_write+0x14b/0x210\n filemap_fdatawrite_wbc+0x5b/0x80\n file_write_and_wait_range+0x6d/0xc0\n nfs_file_fsync+0x81/0x170 [nfs]\n ? nfs_file_mmap+0x60/0x60 [nfs]\n __x64_sys_fsync+0x53/0x90\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nInspecting the core with drgn I was able to pull this\n\n >>> prog.crashed_thread().stack_trace()[0]\n #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27\n >>> prog.crashed_thread().stack_trace()[0]['idx']\n (u32)1\n >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds\n (struct nfs4_ff_layout_ds *)0xffffffffffffffed\n\nThis is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()\nwhich could error out initializing the mirror_ds, and then we go to\nclean it all up and our check is only for if (!mirror->mirror_ds). This\nis inconsistent with the rest of the users of mirror_ds, which have\n\n if (IS_ERR_OR_NULL(mirror_ds))\n\nto keep from tripping over this exact scenario. Fix this up in\nff_layout_cancel_io() to make sure we don't panic when we get an error.\nI also spot checked all the other instances of checking mirror_ds and we\nappear to be doing the correct checks everywhere, only unconditionally\ndereferencing mirror_ds when we know it would be valid.

In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: comedi_8255: Correct error in subdevice initialization\n\nThe refactoring done in commit 5c57b1ccecc7 ("comedi: comedi_8255: Rework\nsubdevice initialization functions") to the initialization of the io\nfield of struct subdev_8255_private broke all cards using the\ndrivers/comedi/drivers/comedi_8255.c module.\n\nPrior to 5c57b1ccecc7, __subdev_8255_init() initialized the io field\nin the newly allocated struct subdev_8255_private to the non-NULL\ncallback given to the function, otherwise it used a flag parameter to\nselect between subdev_8255_mmio and subdev_8255_io. The refactoring\nremoved that logic and the flag, as subdev_8255_mm_init() and\nsubdev_8255_io_init() now explicitly pass subdev_8255_mmio and\nsubdev_8255_io respectively to __subdev_8255_init(), only\n__subdev_8255_init() never sets spriv->io to the supplied\ncallback. That spriv->io is NULL leads to a later BUG:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: 0010 [#1] SMP PTI\nCPU: 1 PID: 1210 Comm: systemd-udevd Not tainted 6.7.3-x86_64 #1\nHardware name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b\nRDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00\nRBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001\nR10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000\nR13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8\nFS: 00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0\nCall Trace:\n <TASK>\n ? __die_body+0x15/0x57\n ? page_fault_oops+0x2ef/0x33c\n ? insert_vmap_area.constprop.0+0xb6/0xd5\n ? alloc_vmap_area+0x529/0x5ee\n ? exc_page_fault+0x15a/0x489\n ? asm_exc_page_fault+0x22/0x30\n __subdev_8255_init+0x79/0x8d [comedi_8255]\n pci_8255_auto_attach+0x11a/0x139 [8255_pci]\n comedi_auto_config+0xac/0x117 [comedi]\n ? __pfx___driver_attach+0x10/0x10\n pci_device_probe+0x88/0xf9\n really_probe+0x101/0x248\n __driver_probe_device+0xbb/0xed\n driver_probe_device+0x1a/0x72\n __driver_attach+0xd4/0xed\n bus_for_each_dev+0x76/0xb8\n bus_add_driver+0xbe/0x1be\n driver_register+0x9a/0xd8\n comedi_pci_driver_register+0x28/0x48 [comedi_pci]\n ? __pfx_pci_8255_driver_init+0x10/0x10 [8255_pci]\n do_one_initcall+0x72/0x183\n do_init_module+0x5b/0x1e8\n init_module_from_file+0x86/0xac\n __do_sys_finit_module+0x151/0x218\n do_syscall_64+0x72/0xdb\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\nRIP: 0033:0x7f72f50a0cb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 71 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007ffd47e512d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\nRAX: ffffffffffffffda RBX: 0000562dd06ae070 RCX: 00007f72f50a0cb9\nRDX: 0000000000000000 RSI: 00007f72f52d32df RDI: 000000000000000e\nRBP: 0000000000000000 R08: 00007f72f5168b20 R09: 0000000000000000\nR10: 0000000000000050 R11: 0000000000000246 R12: 00007f72f52d32df\nR13: 0000000000020000 R14: 0000562dd06785c0 R15: 0000562dcfd0e9a8\n </TASK>\nModules linked in: 8255_pci(+) comedi_8255 comedi_pci comedi intel_gtt e100(+) acpi_cpufreq rtc_cmos usbhid\nCR2: 0000000000000000\n---[ end trace 0000000000000000 ]---\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b\nRDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00\nRBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001\nR10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000\nR13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8\nFS: 00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0\n\nThis patch simply corrects the above mistake by initializing spriv->io\nto the given io callback.

In the Linux kernel, the following vulnerability has been resolved:\n\nrds: tcp: Fix use-after-free of net in reqsk_timer_handler().\n\nsyzkaller reported a warning of netns tracker [0] followed by KASAN\nsplat [1] and another ref tracker warning [1].\n\nsyzkaller could not find a repro, but in the log, the only suspicious\nsequence was as follows:\n\n 18:26:22 executing program 1:\n r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)\n ...\n connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)\n\nThe notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.\n\nSo, the scenario would be:\n\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]\n\nBasically, reqsk assumes that the listener guarantees netns safety\nuntil all reqsk timers are expired by holding the listener's refcount.\nHowever, this was not the case for kernel sockets.\n\nCommit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in\ninet_twsk_purge()") fixed this issue only for per-netns ehash.\n\nLet's apply the same fix for the global ehash.\n\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)\n\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 <IRQ>\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 </IRQ>\n\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_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\nFreed by task 27 on cpu 0 at 329.158864s:\n kasan_save_stack (mm/kasan/common.c:48)\n kasan_save_track (mm/kasan/common.c:68)\n kasan_save_free_info (mm/kasan/generic.c:643)\n __kasan_slab_free (mm/kasan/common.c:265)\n kmem_cache_free (mm/slub.c:4299 mm/slub.c:4363)\n cleanup_net (net/core/net_namespace.c:456 net/core/net_namespace.c:446 net/core/net_namespace.c:639)\n process_one_work (kernel/workqueue.c:2638)\n worker_thread (kernel/workqueue.c:2700 kernel/workqueue.c:2787)\n kthread (kernel/kthread.c:388)\n ret_from_fork (arch/x86/kernel/process.c:153)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:250)\n\nThe buggy address belongs to the object at ffff88801b370000\n which belongs to the cache net_namespace of size 4352\nThe buggy address is located 1024 bytes inside of\n freed 4352-byte region [ffff88801b370000, ffff88801b371100)\n\n[2]:\nWARNING: CPU: 0 PID: 95 at lib/ref_tracker.c:228 ref_tracker_free (lib/ref_tracker.c:228 (discriminator 1))\nModules linked in:\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:ref_tracker_free (lib/ref_tracker.c:228 (discriminator 1))\n...\nCall Trace:\n<IRQ>\n __sk_destruct (./include/net/net_namespace.h:353 net/core/sock.c:2204)\n rcu_core (./arch/x86/include/asm/preempt.h:26 kernel/rcu/tree.c:2165 kernel/rcu/tree.c:2433)\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</IRQ>

In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix refcnt handling in __inet_hash_connect().\n\nsyzbot reported a warning in sk_nulls_del_node_init_rcu().\n\nThe commit 66b60b0c8c4a ("dccp/tcp: Unhash sk from ehash for tb2 alloc\nfailure after check_estalblished().") tried to fix an issue that an\nunconnected socket occupies an ehash entry when bhash2 allocation fails.\n\nIn such a case, we need to revert changes done by check_established(),\nwhich does not hold refcnt when inserting socket into ehash.\n\nSo, to revert the change, we need to __sk_nulls_add_node_rcu() instead\nof sk_nulls_add_node_rcu().\n\nOtherwise, sock_put() will cause refcnt underflow and leak the socket.\n\n[0]:\nWARNING: CPU: 0 PID: 23948 at include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799\nModules linked in:\nCPU: 0 PID: 23948 Comm: syz-executor.2 Not tainted 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nRIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799\nCode: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 <0f> 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2\nRSP: 0018:ffffc900032d7848 EFLAGS: 00010246\nRAX: ffffffff89cd0035 RBX: 0000000000000001 RCX: 0000000000040000\nRDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000\nRBP: 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28\nR10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140\nR13: dffffc0000000000 R14: ffff88802a9bf5c0 R15: ffff888021cd6130\nFS: 00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139\n dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956\n __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678\n inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749\n __sys_connect_file net/socket.c:2048 [inline]\n __sys_connect+0x2df/0x310 net/socket.c:2065\n __do_sys_connect net/socket.c:2075 [inline]\n __se_sys_connect net/socket.c:2072 [inline]\n __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f3b8167dda9\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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX: 00007f3b8167dda9\nRDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 000000000000000b R14: 00007f3b817abf80 R15: 00007ffd3beb57b8\n </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\ndm-integrity: fix a memory leak when rechecking the data\n\nMemory for the "checksums" pointer will leak if the data is rechecked\nafter checksum failure (because the associated kfree won't happen due\nto 'goto skip_io').\n\nFix this by freeing the checksums memory before recheck, and just use\nthe "checksum_onstack" memory for storing checksum during recheck.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadata_map\n\nJust simply reordering the functions mlx5e_ptp_metadata_map_put and\nmlx5e_ptpsq_track_metadata in the mlx5e_txwqe_complete context is not good\nenough since both the compiler and CPU are free to reorder these two\nfunctions. If reordering does occur, the issue that was supposedly fixed by\n7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating\nmetadata map") will be seen. This will lead to NULL pointer dereferences in\nmlx5e_ptpsq_mark_ts_cqes_undelivered in the NAPI polling context due to the\ntracking list being populated before the metadata map.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sparx5: Fix use after free inside sparx5_del_mact_entry\n\nBased on the static analyzis of the code it looks like when an entry\nfrom the MAC table was removed, the entry was still used after being\nfreed. More precise the vid of the mac_entry was used after calling\ndevm_kfree on the mac_entry.\nThe fix consists in first using the vid of the mac_entry to delete the\nentry from the HW and after that to free it.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix uninitialized dplls mutex usage\n\nThe pf->dplls.lock mutex is initialized too late, after its first use.\nMove it to the top of ice_dpll_init.\nNote that the "err_exit" error path destroys the mutex. And the mutex is\nthe last thing destroyed in ice_dpll_deinit.\nThis fixes the following warning with CONFIG_DEBUG_MUTEXES:\n\n ice 0000:10:00.0: The DDP package was successfully loaded: ICE OS Default Package version 1.3.36.0\n ice 0000:10:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link)\n ice 0000:10:00.0: PTP init successful\n ------------[ cut here ]------------\n DEBUG_LOCKS_WARN_ON(lock->magic != lock)\n WARNING: CPU: 0 PID: 410 at kernel/locking/mutex.c:587 __mutex_lock+0x773/0xd40\n Modules linked in: crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni polyval_generic ice(+) nvme nvme_c>\n CPU: 0 PID: 410 Comm: kworker/0:4 Not tainted 6.8.0-rc5+ #3\n Hardware name: HPE ProLiant DL110 Gen10 Plus/ProLiant DL110 Gen10 Plus, BIOS U56 10/19/2023\n Workqueue: events work_for_cpu_fn\n RIP: 0010:__mutex_lock+0x773/0xd40\n Code: c0 0f 84 1d f9 ff ff 44 8b 35 0d 9c 69 01 45 85 f6 0f 85 0d f9 ff ff 48 c7 c6 12 a2 a9 85 48 c7 c7 12 f1 a>\n RSP: 0018:ff7eb1a3417a7ae0 EFLAGS: 00010286\n RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000\n RDX: 0000000000000002 RSI: ffffffff85ac2bff RDI: 00000000ffffffff\n RBP: ff7eb1a3417a7b80 R08: 0000000000000000 R09: 00000000ffffbfff\n R10: ff7eb1a3417a7978 R11: ff32b80f7fd2e568 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: ff32b7f02c50e0d8\n FS: 0000000000000000(0000) GS:ff32b80efe800000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055b5852cc000 CR3: 000000003c43a004 CR4: 0000000000771ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n <TASK>\n ? __warn+0x84/0x170\n ? __mutex_lock+0x773/0xd40\n ? report_bug+0x1c7/0x1d0\n ? prb_read_valid+0x1b/0x30\n ? handle_bug+0x42/0x70\n ? exc_invalid_op+0x18/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? __mutex_lock+0x773/0xd40\n ? rcu_is_watching+0x11/0x50\n ? __kmalloc_node_track_caller+0x346/0x490\n ? ice_dpll_lock_status_get+0x28/0x50 [ice]\n ? __pfx_ice_dpll_lock_status_get+0x10/0x10 [ice]\n ? ice_dpll_lock_status_get+0x28/0x50 [ice]\n ice_dpll_lock_status_get+0x28/0x50 [ice]\n dpll_device_get_one+0x14f/0x2e0\n dpll_device_event_send+0x7d/0x150\n dpll_device_register+0x124/0x180\n ice_dpll_init_dpll+0x7b/0xd0 [ice]\n ice_dpll_init+0x224/0xa40 [ice]\n ? _dev_info+0x70/0x90\n ice_load+0x468/0x690 [ice]\n ice_probe+0x75b/0xa10 [ice]\n ? _raw_spin_unlock_irqrestore+0x4f/0x80\n ? process_one_work+0x1a3/0x500\n local_pci_probe+0x47/0xa0\n work_for_cpu_fn+0x17/0x30\n process_one_work+0x20d/0x500\n worker_thread+0x1df/0x3e0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x103/0x140\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n </TASK>\n irq event stamp: 125197\n hardirqs last enabled at (125197): [<ffffffff8416409d>] finish_task_switch.isra.0+0x12d/0x3d0\n hardirqs last disabled at (125196): [<ffffffff85134044>] __schedule+0xea4/0x19f0\n softirqs last enabled at (105334): [<ffffffff84e1e65a>] napi_get_frags_check+0x1a/0x60\n softirqs last disabled at (105332): [<ffffffff84e1e65a>] napi_get_frags_check+0x1a/0x60\n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: Add protection for bmp length out of range\n\nUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts\nthat are out of bounds for their data type.\n\nvmlinux get_bitmap(b=75) + 712\n<net/netfilter/nf_conntrack_h323_asn1.c:0>\nvmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956\n<net/netfilter/nf_conntrack_h323_asn1.c:592>\nvmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216\n<net/netfilter/nf_conntrack_h323_asn1.c:814>\nvmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812\n<net/netfilter/nf_conntrack_h323_asn1.c:576>\nvmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216\n<net/netfilter/nf_conntrack_h323_asn1.c:814>\nvmlinux DecodeRasMessage() + 304\n<net/netfilter/nf_conntrack_h323_asn1.c:833>\nvmlinux ras_help() + 684\n<net/netfilter/nf_conntrack_h323_main.c:1728>\nvmlinux nf_confirm() + 188\n<net/netfilter/nf_conntrack_proto.c:137>\n\nDue to abnormal data in skb->data, the extension bitmap length\nexceeds 32 when decoding ras message then uses the length to make\na shift operation. It will change into negative after several loop.\nUBSAN load could detect a negative shift as an undefined behaviour\nand reports exception.\nSo we add the protection to avoid the length exceeding 32. Or else\nit will return out of range error and stop decoding.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/debug_vm_pgtable: fix BUG_ON with pud advanced test\n\nArchitectures like powerpc add debug checks to ensure we find only devmap\nPUD pte entries. These debug checks are only done with CONFIG_DEBUG_VM. \nThis patch marks the ptes used for PUD advanced test devmap pte entries so\nthat we don't hit on debug checks on architecture like ppc64 as below.\n\nWARNING: CPU: 2 PID: 1 at arch/powerpc/mm/book3s64/radix_pgtable.c:1382 radix__pud_hugepage_update+0x38/0x138\n....\nNIP [c0000000000a7004] radix__pud_hugepage_update+0x38/0x138\nLR [c0000000000a77a8] radix__pudp_huge_get_and_clear+0x28/0x60\nCall Trace:\n[c000000004a2f950] [c000000004a2f9a0] 0xc000000004a2f9a0 (unreliable)\n[c000000004a2f980] [000d34c100000000] 0xd34c100000000\n[c000000004a2f9a0] [c00000000206ba98] pud_advanced_tests+0x118/0x334\n[c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48\n[c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388\n\nAlso\n\n kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:202!\n ....\n\n NIP [c000000000096510] pudp_huge_get_and_clear_full+0x98/0x174\n LR [c00000000206bb34] pud_advanced_tests+0x1b4/0x334\n Call Trace:\n [c000000004a2f950] [000d34c100000000] 0xd34c100000000 (unreliable)\n [c000000004a2f9a0] [c00000000206bb34] pud_advanced_tests+0x1b4/0x334\n [c000000004a2fa40] [c00000000206db34] debug_vm_pgtable+0xcbc/0x1c48\n [c000000004a2fc10] [c00000000000fd28] do_one_initcall+0x60/0x388

In the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: add nla be16/32 types to minlen array\n\nBUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline]\nBUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline]\nBUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline]\nBUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631\n nla_validate_range_unsigned lib/nlattr.c:222 [inline]\n nla_validate_int_range lib/nlattr.c:336 [inline]\n validate_nla lib/nlattr.c:575 [inline]\n...\n\nThe message in question matches this policy:\n\n [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255),\n\nbut because NLA_BE32 size in minlen array is 0, the validation\ncode will read past the malformed (too small) attribute.\n\nNote: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing:\nthose likely should be added too.

In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/rtas: use correct function name for resetting TCE tables\n\nThe PAPR spec spells the function name as\n\n "ibm,reset-pe-dma-windows"\n\nbut in practice firmware uses the singular form:\n\n "ibm,reset-pe-dma-window"\n\nin the device tree. Since we have the wrong spelling in the RTAS\nfunction table, reverse lookups (token -> name) fail and warn:\n\n unexpected failed lookup for token 86\n WARNING: CPU: 1 PID: 545 at arch/powerpc/kernel/rtas.c:659 __do_enter_rtas_trace+0x2a4/0x2b4\n CPU: 1 PID: 545 Comm: systemd-udevd Not tainted 6.8.0-rc4 #30\n Hardware name: IBM,9105-22A POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NL1060_028) hv:phyp pSeries\n NIP [c0000000000417f0] __do_enter_rtas_trace+0x2a4/0x2b4\n LR [c0000000000417ec] __do_enter_rtas_trace+0x2a0/0x2b4\n Call Trace:\n __do_enter_rtas_trace+0x2a0/0x2b4 (unreliable)\n rtas_call+0x1f8/0x3e0\n enable_ddw.constprop.0+0x4d0/0xc84\n dma_iommu_dma_supported+0xe8/0x24c\n dma_set_mask+0x5c/0xd8\n mlx5_pci_init.constprop.0+0xf0/0x46c [mlx5_core]\n probe_one+0xfc/0x32c [mlx5_core]\n local_pci_probe+0x68/0x12c\n pci_call_probe+0x68/0x1ec\n pci_device_probe+0xbc/0x1a8\n really_probe+0x104/0x570\n __driver_probe_device+0xb8/0x224\n driver_probe_device+0x54/0x130\n __driver_attach+0x158/0x2b0\n bus_for_each_dev+0xa8/0x120\n driver_attach+0x34/0x48\n bus_add_driver+0x174/0x304\n driver_register+0x8c/0x1c4\n __pci_register_driver+0x68/0x7c\n mlx5_init+0xb8/0x118 [mlx5_core]\n do_one_initcall+0x60/0x388\n do_init_module+0x7c/0x2a4\n init_module_from_file+0xb4/0x108\n idempotent_init_module+0x184/0x34c\n sys_finit_module+0x90/0x114\n\nAnd oopses are possible when lockdep is enabled or the RTAS\ntracepoints are active, since those paths dereference the result of\nthe lookup.\n\nUse the correct spelling to match firmware's behavior, adjusting the\nrelated constants to match.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix KASAN issue with tasklet\n\nKASAN testing revealed the following issue assocated with freeing an IRQ.\n\n[50006.466686] Call Trace:\n[50006.466691] <IRQ>\n[50006.489538] dump_stack+0x5c/0x80\n[50006.493475] print_address_description.constprop.6+0x1a/0x150\n[50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma]\n[50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma]\n[50006.511644] kasan_report.cold.11+0x7f/0x118\n[50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma]\n[50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma]\n[50006.528232] irdma_process_ceq+0xb2/0x400 [irdma]\n[50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma]\n[50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma]\n[50006.545306] tasklet_action_common.isra.14+0x148/0x2c0\n[50006.551096] __do_softirq+0x1d0/0xaf8\n[50006.555396] irq_exit_rcu+0x219/0x260\n[50006.559670] irq_exit+0xa/0x20\n[50006.563320] smp_apic_timer_interrupt+0x1bf/0x690\n[50006.568645] apic_timer_interrupt+0xf/0x20\n[50006.573341] </IRQ>\n\nThe issue is that a tasklet could be pending on another core racing\nthe delete of the irq.\n\nFix by insuring any scheduled tasklet is killed after deleting the\nirq.

In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: think-lmi: Fix password opcode ordering for workstations\n\nThe Lenovo workstations require the password opcode to be run before\nthe attribute value is changed (if Admin password is enabled).\n\nTested on some Thinkpads to confirm they are OK with this order too.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: set dormant flag on hook register failure\n\nWe need to set the dormant flag again if we fail to register\nthe hooks.\n\nDuring memory pressure hook registration can fail and we end up\nwith a table marked as active but no registered hooks.\n\nOn table/base chain deletion, nf_tables will attempt to unregister\nthe hook again which yields a warn splat from the nftables core.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_flow_offload: release dst in case direct xmit path is used\n\nDirect xmit does not use it since it calls dev_queue_xmit() to send\npackets, hence it calls dst_release().\n\nkmemleak reports:\n\nunreferenced object 0xffff88814f440900 (size 184):\n comm "softirq", pid 0, jiffies 4294951896\n hex dump (first 32 bytes):\n 00 60 5b 04 81 88 ff ff 00 e6 e8 82 ff ff ff ff .`[.............\n 21 0b 50 82 ff ff ff ff 00 00 00 00 00 00 00 00 !.P.............\n backtrace (crc cb2bf5d6):\n [<000000003ee17107>] kmem_cache_alloc+0x286/0x340\n [<0000000021a5de2c>] dst_alloc+0x43/0xb0\n [<00000000f0671159>] rt_dst_alloc+0x2e/0x190\n [<00000000fe5092c9>] __mkroute_output+0x244/0x980\n [<000000005fb96fb0>] ip_route_output_flow+0xc0/0x160\n [<0000000045367433>] nf_ip_route+0xf/0x30\n [<0000000085da1d8e>] nf_route+0x2d/0x60\n [<00000000d1ecd1cb>] nft_flow_route+0x171/0x6a0 [nft_flow_offload]\n [<00000000d9b2fb60>] nft_flow_offload_eval+0x4e8/0x700 [nft_flow_offload]\n [<000000009f447dbb>] expr_call_ops_eval+0x53/0x330 [nf_tables]\n [<00000000072e1be6>] nft_do_chain+0x17c/0x840 [nf_tables]\n [<00000000d0551029>] nft_do_chain_inet+0xa1/0x210 [nf_tables]\n [<0000000097c9d5c6>] nf_hook_slow+0x5b/0x160\n [<0000000005eccab1>] ip_forward+0x8b6/0x9b0\n [<00000000553a269b>] ip_rcv+0x221/0x230\n [<00000000412872e5>] __netif_receive_skb_one_core+0xfe/0x110

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: fix missing folio cleanup in writeback race path\n\nIn zswap_writeback_entry(), after we get a folio from\n__read_swap_cache_async(), we grab the tree lock again to check that the\nswap entry was not invalidated and recycled. If it was, we delete the\nfolio we just added to the swap cache and exit.\n\nHowever, __read_swap_cache_async() returns the folio locked when it is\nnewly allocated, which is always true for this path, and the folio is\nref'd. Make sure to unlock and put the folio before returning.\n\nThis was discovered by code inspection, probably because this path handles\na race condition that should not happen often, and the bug would not crash\nthe system, it will only strand the folio indefinitely.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/handshake: Fix handshake_req_destroy_test1\n\nRecently, handshake_req_destroy_test1 started failing:\n\nExpected handshake_req_destroy_test == req, but\n handshake_req_destroy_test == 0000000000000000\n req == 0000000060f99b40\nnot ok 11 req_destroy works\n\nThis is because "sock_release(sock)" was replaced with "fput(filp)"\nto address a memory leak. Note that sock_release() is synchronous\nbut fput() usually delays the final close and clean-up.\n\nThe delay is not consequential in the other cases that were changed\nbut handshake_req_destroy_test1 is testing that handshake_req_cancel()\nfollowed by closing the file actually does call the ->hp_destroy\nmethod. Thus the PTR_EQ test at the end has to be sure that the\nfinal close is complete before it checks the pointer.\n\nWe cannot use a completion here because if ->hp_destroy is never\ncalled (ie, there is an API bug) then the test will hang.\n\nReported by: Guenter Roeck <linux@roeck-us.net>

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ir_toy: fix a memleak in irtoy_tx\n\nWhen irtoy_command fails, buf should be freed since it is allocated by\nirtoy_tx, or there is a memleak.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_hash - Remove bogus SGL free on zero-length error path\n\nWhen a zero-length message is hashed by algif_hash, and an error\nis triggered, it tries to free an SG list that was never allocated\nin the first place. Fix this by not freeing the SG list on the\nzero-length error path.

In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gic-v3-its: Restore quirk probing for ACPI-based systems\n\nWhile refactoring the way the ITSs are probed, the handling of quirks\napplicable to ACPI-based platforms was lost. As a result, systems such as\nHIP07 lose their GICv4 functionnality, and some other may even fail to\nboot, unless they are configured to boot with DT.\n\nMove the enabling of quirks into its_probe_one(), making it common to all\nfirmware implementations.

In the Linux kernel, the following vulnerability has been resolved:\n\nhv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed\n\nIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER\nhandler cannot perform VF register successfully as the register call\nis received before netvsc_probe is finished. This is because we\nregister register_netdevice_notifier() very early( even before\nvmbus_driver_register()).\nTo fix this, we try to register each such matching VF( if it is visible\nas a netdevice) at the end of netvsc_probe.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio\n\nIf kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the\nfollowing kernel warning appears:\n\nWARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8\nCall trace:\n kiocb_set_cancel_fn+0x9c/0xa8\n ffs_epfile_read_iter+0x144/0x1d0\n io_read+0x19c/0x498\n io_issue_sqe+0x118/0x27c\n io_submit_sqes+0x25c/0x5fc\n __arm64_sys_io_uring_enter+0x104/0xab0\n invoke_syscall+0x58/0x11c\n el0_svc_common+0xb4/0xf4\n do_el0_svc+0x2c/0xb0\n el0_svc+0x2c/0xa4\n el0t_64_sync_handler+0x68/0xb4\n el0t_64_sync+0x1a4/0x1a8\n\nFix this by setting the IOCB_AIO_RW flag for read and write I/O that is\nsubmitted by libaio.

In the Linux kernel, the following vulnerability has been resolved:\n\ndm-crypt: don't modify the data when using authenticated encryption\n\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.\n\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.\n\n[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/

In the Linux kernel, the following vulnerability has been resolved:\n\nceph: prevent use-after-free in encode_cap_msg()\n\nIn fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was\ncaught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This\nimplies before the refcount could be increment here, it was freed.\n\nIn same file, in "handle_cap_grant()" refcount is decremented by this\nline - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race\noccurred and resource was freed by the latter line before the former\nline could increment it.\n\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->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where\nthe refcount must be increased to prevent "use after free" error.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super\n\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->hstate in hugetlbfs_parse_param() when the requested pagesize\nis non valid.\n\nE.g: Taking the following steps:\n\n fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC);\n fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0);\n fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);\n\nGiven that the requested "pagesize" is invalid, ctxt->hstate will be replaced\nwith NULL, losing its previous value, and we will print an error:\n\n ...\n ...\n case Opt_pagesize:\n ps = memparse(param->string, &rest);\n ctx->hstate = h;\n if (!ctx->hstate) {\n pr_err("Unsupported page size %lu MB\\n", ps / SZ_1M);\n return -EINVAL;\n }\n return 0;\n ...\n ...\n\nThis is a problem because later on, we will dereference ctxt->hstate in\nhugetlbfs_fill_super()\n\n ...\n ...\n sb->s_blocksize = huge_page_size(ctx->hstate);\n ...\n ...\n\nCausing below Oops.\n\nFix this by replacing cxt->hstate value only when then pagesize is known\nto be valid.\n\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 <8b> 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: \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 <48> 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---

In the Linux kernel, the following vulnerability has been resolved:\n\ntty: n_gsm: fix race condition in status line change on dead connections\n\ngsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all\ntimers, removing the virtual tty devices and clearing the data queues.\nThis procedure, however, may cause subsequent changes of the virtual modem\nstatus lines of a DLCI. More data is being added the outgoing data queue\nand the deleted kick timer is restarted to handle this. At this point many\nresources have already been removed by the cleanup procedure. Thus, a\nkernel panic occurs.\n\nFix this by proving in gsm_modem_update() that the cleanup procedure has\nnot been started and the mux is still alive.\n\nNote that writing to a virtual tty is already protected by checks against\nthe DLCI specific connection state.

In the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: Fix user-memory-access bug in uclogic_params_ugee_v2_init_event_hooks()\n\nWhen CONFIG_HID_UCLOGIC=y and CONFIG_KUNIT_ALL_TESTS=y, launch kernel and\nthen the below user-memory-access bug occurs.\n\nIn hid_test_uclogic_params_cleanup_event_hooks(),it call\nuclogic_params_ugee_v2_init_event_hooks() with the first arg=NULL, so\nwhen it calls uclogic_params_ugee_v2_has_battery(), the hid_get_drvdata()\nwill access hdev->dev with hdev=NULL, which will cause below\nuser-memory-access.\n\nSo add a fake_device with quirks member and call hid_set_drvdata()\nto assign hdev->dev->driver_data which avoids the null-ptr-def bug\nfor drvdata->quirks in uclogic_params_ugee_v2_has_battery(). After applying\nthis patch, the below user-memory-access bug never occurs.\n\n general protection fault, probably for non-canonical address 0xdffffc0000000329: 0000 [#1] PREEMPT SMP KASAN\n KASAN: probably user-memory-access in range [0x0000000000001948-0x000000000000194f]\n CPU: 5 PID: 2189 Comm: kunit_try_catch Tainted: G B W N 6.6.0-rc2+ #30\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600\n Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 <80> 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00\n RSP: 0000:ffff88810679fc88 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000\n RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948\n RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0\n R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92\n R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080\n FS: 0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0\n DR0: ffffffff8fdd6cf4 DR1: ffffffff8fdd6cf5 DR2: ffffffff8fdd6cf6\n DR3: ffffffff8fdd6cf7 DR6: 00000000fffe0ff0 DR7: 0000000000000600\n PKRU: 55555554\n Call Trace:\n <TASK>\n ? die_addr+0x3d/0xa0\n ? exc_general_protection+0x144/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? uclogic_params_ugee_v2_init_event_hooks+0x87/0x600\n ? sched_clock_cpu+0x69/0x550\n ? uclogic_parse_ugee_v2_desc_gen_params+0x70/0x70\n ? load_balance+0x2950/0x2950\n ? rcu_trc_cmpxchg_need_qs+0x67/0xa0\n hid_test_uclogic_params_cleanup_event_hooks+0x9e/0x1a0\n ? uclogic_params_ugee_v2_init_event_hooks+0x600/0x600\n ? __switch_to+0x5cf/0xe60\n ? migrate_enable+0x260/0x260\n ? __kthread_parkme+0x83/0x150\n ? kunit_try_run_case_cleanup+0xe0/0xe0\n kunit_generic_run_threadfn_adapter+0x4a/0x90\n ? kunit_try_catch_throw+0x80/0x80\n kthread+0x2b5/0x380\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x2d/0x70\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork_asm+0x11/0x20\n </TASK>\n Modules linked in:\n Dumping ftrace buffer:\n (ftrace buffer empty)\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600\n Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 <80> 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00\n RSP: 0000:ffff88810679fc88 EFLAGS: 00010202\n RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000\n RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948\n RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0\n R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92\n R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080\n FS: 0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0\n DR0: ffffffff8fdd6cf4 DR1: ffffffff8fdd6cf5 DR2: ffffffff8fdd6cf6\n DR3: ffffffff8fdd6cf7 DR6: 00000000fffe0ff0 DR7: 0000000000000600\n PKRU: 55555554\n Kernel panic - not syncing: Fatal exception\n Dumping ftrace buffer:\n (ftrace buffer empty)\n Kernel Offset: disabled\n Rebooting in 1 seconds..

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix null pointer dereference in error message\n\nThis patch fixes a null pointer dereference in the error message that is\nprinted when the Display Core (DC) fails to initialize. The original\nmessage includes the DC version number, which is undefined if the DC is\nnot initialized.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: bridge: it66121: Fix invalid connector dereference\n\nFix the NULL pointer dereference when no monitor is connected, and the\nsound card is opened from userspace.\n\nInstead return an empty buffer (of zeroes) as the EDID information to\nthe sound framework if there is no connector attached.

In the Linux kernel, the following vulnerability has been resolved:\n\nperf: hisi: Fix use-after-free when register pmu fails\n\nWhen we fail to register the uncore pmu, the pmu context may not been\nallocated. The error handing will call cpuhp_state_remove_instance()\nto call uncore pmu offline callback, which migrate the pmu context.\nSince that's liable to lead to some kind of use-after-free.\n\nUse cpuhp_state_remove_instance_nocalls() instead of\ncpuhp_state_remove_instance() so that the notifiers don't execute after\nthe PMU device has been failed to register.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Fix coverity issue with unintentional integer overflow\n\n1. Instead of multiplying 2 variable of different types. Change to\nassign a value of one variable and then multiply the other variable.\n\n2. Add a int variable for multiplier calculation instead of calculating\ndifferent types multiplier with dma_addr_t variable directly.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/bridge: lt8912b: Fix crash on bridge detach\n\nThe lt8912b driver, in its bridge detach function, calls\ndrm_connector_unregister() and drm_connector_cleanup().\n\ndrm_connector_unregister() should be called only for connectors\nexplicitly registered with drm_connector_register(), which is not the\ncase in lt8912b.\n\nThe driver's drm_connector_funcs.destroy hook is set to\ndrm_connector_cleanup().\n\nThus the driver should not call either drm_connector_unregister() nor\ndrm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a\ncrash on bridge detach:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem abort info:\n ESR = 0x0000000096000006\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=00000000858f3000\n[0000000000000000] pgd=0800000085918003, p4d=0800000085918003, pud=0800000085431003, pmd=0000000000000000\nInternal error: Oops: 0000000096000006 [#1] PREEMPT SMP\nModules linked in: tidss(-) display_connector lontium_lt8912b tc358768 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks\nCPU: 3 PID: 462 Comm: rmmod Tainted: G W 6.5.0-rc2+ #2\nHardware name: Toradex Verdin AM62 on Verdin Development Board (DT)\npstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : drm_connector_cleanup+0x78/0x2d4 [drm]\nlr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]\nsp : ffff800082ed3a90\nx29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000\nx26: 0000000000000000 x25: dead000000000122 x24: dead000000000122\nx23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000\nx20: 0000000000000000 x19: ffff000003fb6260 x18: fffffffffffe56e8\nx17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038\nx14: 0000000000000000 x13: ffff800081914b48 x12: 000000000000040e\nx11: 000000000000015a x10: ffff80008196ebb8 x9 : ffff800081914b48\nx8 : 00000000ffffefff x7 : ffff0000040c1940 x6 : ffff80007aa649d0\nx5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008159e008\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\nCall trace:\n drm_connector_cleanup+0x78/0x2d4 [drm]\n lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]\n drm_bridge_detach+0x44/0x84 [drm]\n drm_encoder_cleanup+0x40/0xb8 [drm]\n drmm_encoder_alloc_release+0x1c/0x30 [drm]\n drm_managed_release+0xac/0x148 [drm]\n drm_dev_put.part.0+0x88/0xb8 [drm]\n devm_drm_dev_init_release+0x14/0x24 [drm]\n devm_action_release+0x14/0x20\n release_nodes+0x5c/0x90\n devres_release_all+0x8c/0xe0\n device_unbind_cleanup+0x18/0x68\n device_release_driver_internal+0x208/0x23c\n driver_detach+0x4c/0x94\n bus_remove_driver+0x70/0xf4\n driver_unregister+0x30/0x60\n platform_driver_unregister+0x14/0x20\n tidss_platform_driver_exit+0x18/0xb2c [tidss]\n __arm64_sys_delete_module+0x1a0/0x2b4\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x60/0x10c\n do_el0_svc_compat+0x1c/0x40\n el0_svc_compat+0x40/0xac\n el0t_32_sync_handler+0xb0/0x138\n el0t_32_sync+0x194/0x198\nCode: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420)

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: compress: fix to avoid use-after-free on dic\n\nCall trace:\n __memcpy+0x128/0x250\n f2fs_read_multi_pages+0x940/0xf7c\n f2fs_mpage_readpages+0x5a8/0x624\n f2fs_readahead+0x5c/0x110\n page_cache_ra_unbounded+0x1b8/0x590\n do_sync_mmap_readahead+0x1dc/0x2e4\n filemap_fault+0x254/0xa8c\n f2fs_filemap_fault+0x2c/0x104\n __do_fault+0x7c/0x238\n do_handle_mm_fault+0x11bc/0x2d14\n do_mem_abort+0x3a8/0x1004\n el0_da+0x3c/0xa0\n el0t_64_sync_handler+0xc4/0xec\n el0t_64_sync+0x1b4/0x1b8\n\nIn f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if\nwe hit cached page in compress_inode's cache, dic may be released, it needs\nbreak the loop rather than continuing it, in order to avoid accessing\ninvalid dic pointer.

In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF\n\nIn the unlikely event that workqueue allocation fails and returns NULL in\nmlx5_mkey_cache_init(), delete the call to\nmlx5r_umr_resource_cleanup() (which frees the QP) in\nmlx5_ib_stage_post_ib_reg_umr_init(). This will avoid attempted double\nfree of the same QP when __mlx5_ib_add() does its cleanup.\n\nResolves a splat:\n\n Syzkaller reported a UAF in ib_destroy_qp_user\n\n workqueue: Failed to create a rescuer kthread for wq "mkey_cache": -EINTR\n infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642):\n failed to create work queue\n infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075:(pid 1642):\n mr cache init failed -12\n ==================================================================\n BUG: KASAN: slab-use-after-free in ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)\n Read of size 8 at addr ffff88810da310a8 by task repro_upstream/1642\n\n Call Trace:\n <TASK>\n kasan_report (mm/kasan/report.c:590)\n ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)\n mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)\n __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4178)\n mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)\n ...\n </TASK>\n\n Allocated by task 1642:\n __kmalloc (./include/linux/kasan.h:198 mm/slab_common.c:1026\n mm/slab_common.c:1039)\n create_qp (./include/linux/slab.h:603 ./include/linux/slab.h:720\n ./include/rdma/ib_verbs.h:2795 drivers/infiniband/core/verbs.c:1209)\n ib_create_qp_kernel (drivers/infiniband/core/verbs.c:1347)\n mlx5r_umr_resource_init (drivers/infiniband/hw/mlx5/umr.c:164)\n mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4070)\n __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)\n mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)\n ...\n\n Freed by task 1642:\n __kmem_cache_free (mm/slub.c:1826 mm/slub.c:3809 mm/slub.c:3822)\n ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2112)\n mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)\n mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4076\n drivers/infiniband/hw/mlx5/main.c:4065)\n __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)\n mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)\n ...

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: hantro: Check whether reset op is defined before use\n\nThe i.MX8MM/N/P does not define the .reset op since reset of the VPU is\ndone by genpd. Check whether the .reset op is defined before calling it\nto avoid NULL pointer dereference.\n\nNote that the Fixes tag is set to the commit which removed the reset op\nfrom i.MX8M Hantro G2 implementation, this is because before this commit\nall the implementations did define the .reset op.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/mem: Fix shutdown order\n\nIra reports that removing cxl_mock_mem causes a crash with the following\ntrace:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000044\n [..]\n RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core]\n [..]\n Call Trace:\n <TASK>\n cxl_region_detach+0xe8/0x210 [cxl_core]\n cxl_decoder_kill_region+0x27/0x40 [cxl_core]\n cxld_unregister+0x29/0x40 [cxl_core]\n devres_release_all+0xb8/0x110\n device_unbind_cleanup+0xe/0x70\n device_release_driver_internal+0x1d2/0x210\n bus_remove_device+0xd7/0x150\n device_del+0x155/0x3e0\n device_unregister+0x13/0x60\n devm_release_action+0x4d/0x90\n ? __pfx_unregister_port+0x10/0x10 [cxl_core]\n delete_endpoint+0x121/0x130 [cxl_core]\n devres_release_all+0xb8/0x110\n device_unbind_cleanup+0xe/0x70\n device_release_driver_internal+0x1d2/0x210\n bus_remove_device+0xd7/0x150\n device_del+0x155/0x3e0\n ? lock_release+0x142/0x290\n cdev_device_del+0x15/0x50\n cxl_memdev_unregister+0x54/0x70 [cxl_core]\n\nThis crash is due to the clearing out the cxl_memdev's driver context\n(@cxlds) before the subsystem is done with it. This is ultimately due to\nthe region(s), that this memdev is a member, being torn down and expecting\nto be able to de-reference @cxlds, like here:\n\nstatic int cxl_region_decode_reset(struct cxl_region *cxlr, int count)\n...\n if (cxlds->rcd)\n goto endpoint_reset;\n...\n\nFix it by keeping the driver context valid until memdev-device\nunregistration, and subsequently the entire stack of related\ndependencies, unwinds.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to drop meta_inode's page cache in f2fs_put_super()\n\nsyzbot reports a kernel bug as below:\n\nF2FS-fs (loop1): detect filesystem reference count leak during umount, type: 10, count: 1\nkernel BUG at fs/f2fs/super.c:1639!\nCPU: 0 PID: 15451 Comm: syz-executor.1 Not tainted 6.5.0-syzkaller-09338-ge0152e7481c6 #0\nRIP: 0010:f2fs_put_super+0xce1/0xed0 fs/f2fs/super.c:1639\nCall Trace:\n generic_shutdown_super+0x161/0x3c0 fs/super.c:693\n kill_block_super+0x3b/0x70 fs/super.c:1646\n kill_f2fs_super+0x2b7/0x3d0 fs/f2fs/super.c:4879\n deactivate_locked_super+0x9a/0x170 fs/super.c:481\n deactivate_super+0xde/0x100 fs/super.c:514\n cleanup_mnt+0x222/0x3d0 fs/namespace.c:1254\n task_work_run+0x14d/0x240 kernel/task_work.c:179\n resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:171 [inline]\n exit_to_user_mode_prepare+0x210/0x240 kernel/entry/common.c:204\n __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]\n syscall_exit_to_user_mode+0x1d/0x60 kernel/entry/common.c:296\n do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nIn f2fs_put_super(), it tries to do sanity check on dirty and IO\nreference count of f2fs, once there is any reference count leak,\nit will trigger panic.\n\nThe root case is, during f2fs_put_super(), if there is any IO error\nin f2fs_wait_on_all_pages(), we missed to truncate meta_inode's page\ncache later, result in panic, fix this case.

In the Linux kernel, the following vulnerability has been resolved:\n\nllc: verify mac len before reading mac header\n\nLLC reads the mac header with eth_hdr without verifying that the skb\nhas an Ethernet header.\n\nSyzbot was able to enter llc_rcv on a tun device. Tun can insert\npackets without mac len and with user configurable skb->protocol\n(passing a tun_pi header when not configuring IFF_NO_PI).\n\n BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]\n llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111\n llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218\n __netif_receive_skb_one_core net/core/dev.c:5523 [inline]\n __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637\n netif_receive_skb_internal net/core/dev.c:5723 [inline]\n netif_receive_skb+0x58/0x660 net/core/dev.c:5782\n tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555\n tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002\n\nAdd a mac_len test before all three eth_hdr(skb) calls under net/llc.\n\nThere are further uses in include/net/llc_pdu.h. All these are\nprotected by a test skb->protocol == ETH_P_802_2. Which does not\nprotect against this tun scenario.\n\nBut the mac_len test added in this patch in llc_fixup_skb will\nindirectly protect those too. That is called from llc_rcv before any\nother LLC code.\n\nIt is tempting to just add a blanket mac_len check in llc_rcv, but\nnot sure whether that could break valid LLC paths that do not assume\nan Ethernet header. 802.2 LLC may be used on top of non-802.3\nprotocols in principle. The below referenced commit shows that used\nto, on top of Token Ring.\n\nAt least one of the three eth_hdr uses goes back to before the start\nof git history. But the one that syzbot exercises is introduced in\nthis commit. That commit is old enough (2008), that effectively all\nstable kernels should receive this.

In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio/vsock: Fix uninit-value in virtio_transport_recv_pkt()\n\nKMSAN reported the following uninit-value access issue:\n\n=====================================================\nBUG: KMSAN: uninit-value in virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421\n virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421\n vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120\n process_one_work kernel/workqueue.c:2630 [inline]\n process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703\n worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784\n kthread+0x3cc/0x520 kernel/kthread.c:388\n ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\n\nUninit was stored to memory at:\n virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [inline]\n virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virtio_transport_common.c:1415\n vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120\n process_one_work kernel/workqueue.c:2630 [inline]\n process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703\n worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784\n kthread+0x3cc/0x520 kernel/kthread.c:388\n ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\n\nUninit was created at:\n slab_post_alloc_hook+0x105/0xad0 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c:3523\n kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:559\n __alloc_skb+0x2fd/0x770 net/core/skbuff.c:650\n alloc_skb include/linux/skbuff.h:1286 [inline]\n virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [inline]\n virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c:58\n virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [inline]\n virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387\n vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120\n process_one_work kernel/workqueue.c:2630 [inline]\n process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703\n worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784\n kthread+0x3cc/0x520 kernel/kthread.c:388\n ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\n\nCPU: 1 PID: 10664 Comm: kworker/1:5 Not tainted 6.6.0-rc3-00146-g9f3ebbef746f #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014\nWorkqueue: vsock-loopback vsock_loopback_work\n=====================================================\n\nThe following simple reproducer can cause the issue described above:\n\nint main(void)\n{\n int sock;\n struct sockaddr_vm addr = {\n .svm_family = AF_VSOCK,\n .svm_cid = VMADDR_CID_ANY,\n .svm_port = 1234,\n };\n\n sock = socket(AF_VSOCK, SOCK_STREAM, 0);\n connect(sock, (struct sockaddr *)&addr, sizeof(addr));\n return 0;\n}\n\nThis issue occurs because the `buf_alloc` and `fwd_cnt` fields of the\n`struct virtio_vsock_hdr` are not initialized when a new skb is allocated\nin `virtio_transport_init_hdr()`. This patch resolves the issue by\ninitializing these fields during allocation.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: perf: Do not broadcast to other cpus when starting a counter\n\nThis command:\n\n$ perf record -e cycles:k -e instructions:k -c 10000 -m 64M dd if=/dev/zero of=/dev/null count=1000\n\ngives rise to this kernel warning:\n\n[ 444.364395] WARNING: CPU: 0 PID: 104 at kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436\n[ 444.364515] Modules linked in:\n[ 444.364657] CPU: 0 PID: 104 Comm: perf-exec Not tainted 6.6.0-rc6-00051-g391df82e8ec3-dirty #73\n[ 444.364771] Hardware name: riscv-virtio,qemu (DT)\n[ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436\n[ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32\n[ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800\n[ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0\n[ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0\n[ 444.364998] s1 : ff60000002c54d98 a0 : ff60000002a73940 a1 : 0000000000000000\n[ 444.365013] a2 : 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100\n[ 444.365029] a5 : 0000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000\n[ 444.365044] s2 : 0000000000000000 s3 : ffffffffffffffff s4 : ff60000002c54d98\n[ 444.365060] s5 : ffffffff81539610 s6 : ffffffff80c20c48 s7 : 0000000000000000\n[ 444.365075] s8 : 0000000000000000 s9 : 0000000000000001 s10: 0000000000000001\n[ 444.365090] s11: ffffffff80099394 t3 : 0000000000000003 t4 : 00000000eac0c6e6\n[ 444.365104] t5 : 0000000400000000 t6 : ff60000002e010d0\n[ 444.365120] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003\n[ 444.365226] [<ffffffff8009f9e0>] smp_call_function_many_cond+0x42c/0x436\n[ 444.365295] [<ffffffff8009fa5a>] on_each_cpu_cond_mask+0x20/0x32\n[ 444.365311] [<ffffffff806e90dc>] pmu_sbi_ctr_start+0x7a/0xaa\n[ 444.365327] [<ffffffff806e880c>] riscv_pmu_start+0x48/0x66\n[ 444.365339] [<ffffffff8012111a>] perf_adjust_freq_unthr_context+0x196/0x1ac\n[ 444.365356] [<ffffffff801237aa>] perf_event_task_tick+0x78/0x8c\n[ 444.365368] [<ffffffff8003faf4>] scheduler_tick+0xe6/0x25e\n[ 444.365383] [<ffffffff8008a042>] update_process_times+0x80/0x96\n[ 444.365398] [<ffffffff800991ec>] tick_sched_handle+0x26/0x52\n[ 444.365410] [<ffffffff800993e4>] tick_sched_timer+0x50/0x98\n[ 444.365422] [<ffffffff8008a6aa>] __hrtimer_run_queues+0x126/0x18a\n[ 444.365433] [<ffffffff8008b350>] hrtimer_interrupt+0xce/0x1da\n[ 444.365444] [<ffffffff806cdc60>] riscv_timer_interrupt+0x30/0x3a\n[ 444.365457] [<ffffffff8006afa6>] handle_percpu_devid_irq+0x80/0x114\n[ 444.365470] [<ffffffff80065b82>] generic_handle_domain_irq+0x1c/0x2a\n[ 444.365483] [<ffffffff8045faec>] riscv_intc_irq+0x2e/0x46\n[ 444.365497] [<ffffffff808a9c62>] handle_riscv_irq+0x4a/0x74\n[ 444.365521] [<ffffffff808aa760>] do_irq+0x7c/0x7e\n[ 444.365796] ---[ end trace 0000000000000000 ]---\n\nThat's because the fix in commit 3fec323339a4 ("drivers: perf: Fix panic\nin riscv SBI mmap support") was wrong since there is no need to broadcast\nto other cpus when starting a counter, that's only needed in mmap when\nthe counters could have already been started on other cpus, so simply\nremove this broadcast.

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: imsttfb: fix a resource leak in probe\n\nI've re-written the error handling but the bug is that if init_imstt()\nfails we need to call iounmap(par->cmap_regs).

In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix uaf in nbd_open\n\nCommit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and\nblk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set\ndisk->private_data as NULL as before. UAF may be triggered in nbd_open()\nif someone tries to open nbd device right after nbd_put() since nbd has\nbeen free in nbd_dev_remove().\n\nFix this by implementing ->free_disk and free private data in it.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats()\n\nlen is extracted from HTT message and could be an unexpected value in\ncase errors happen, so add validation before using to avoid possible\nout-of-bound read in the following message iteration and parsing.\n\nThe same issue also applies to ppdu_info->ppdu_stats.common.num_users,\nso validate it before using too.\n\nThese are found during code review.\n\nCompile test only.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/vkms: fix a possible null pointer dereference\n\nIn amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_cvt_mode(). Add a check to avoid null pointer\ndereference.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix potential null pointer derefernce\n\nThe amdgpu_ras_get_context may return NULL if device\nnot support ras feature, so add check before using.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs\n\nThe hns3 driver define an array of string to show the coalesce\ninfo, but if the kernel adds a new mode or a new state,\nout-of-bounds access may occur when coalesce info is read via\ndebugfs, this patch fix the problem.

In the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Fix missing update of domains_itree after splitting iopt_area\n\nIn iopt_area_split(), if the original iopt_area has filled a domain and is\nlinked to domains_itree, pages_nodes have to be properly\nreinserted. Otherwise the domains_itree becomes corrupted and we will UAF.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: perf: Check find_first_bit() return value\n\nWe must check the return value of find_first_bit() before using the\nreturn value as an index array since it happens to overflow the array\nand then panic:\n\n[ 107.318430] Kernel BUG [#1]\n[ 107.319434] CPU: 3 PID: 1238 Comm: kill Tainted: G E 6.6.0-rc6ubuntu-defconfig #2\n[ 107.319465] Hardware name: riscv-virtio,qemu (DT)\n[ 107.319551] epc : pmu_sbi_ovf_handler+0x3a4/0x3ae\n[ 107.319840] ra : pmu_sbi_ovf_handler+0x52/0x3ae\n[ 107.319868] epc : ffffffff80a0a77c ra : ffffffff80a0a42a sp : ffffaf83fecda350\n[ 107.319884] gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480\n[ 107.319899] t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520\n[ 107.319921] s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff\n[ 107.319936] a2 : 0000000001073734 a3 : 0000000000000004 a4 : 0000000000000000\n[ 107.319951] a5 : 0000000000000040 a6 : 000000001d1c8774 a7 : 0000000000504d55\n[ 107.319965] s2 : ffffffff82451f10 s3 : ffffffff82724e70 s4 : 000000000000003f\n[ 107.319980] s5 : 0000000000000011 s6 : ffffaf8083db27c0 s7 : 0000000000000000\n[ 107.319995] s8 : 0000000000000001 s9 : 00007fffb45d6558 s10: 00007fffb45d81a0\n[ 107.320009] s11: ffffaf7ffff60000 t3 : 0000000000000004 t4 : 0000000000000000\n[ 107.320023] t5 : ffffaf7f80000000 t6 : ffffaf8000000000\n[ 107.320037] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003\n[ 107.320081] [<ffffffff80a0a77c>] pmu_sbi_ovf_handler+0x3a4/0x3ae\n[ 107.320112] [<ffffffff800b42d0>] handle_percpu_devid_irq+0x9e/0x1a0\n[ 107.320131] [<ffffffff800ad92c>] generic_handle_domain_irq+0x28/0x36\n[ 107.320148] [<ffffffff8065f9f8>] riscv_intc_irq+0x36/0x4e\n[ 107.320166] [<ffffffff80caf4a0>] handle_riscv_irq+0x54/0x86\n[ 107.320189] [<ffffffff80cb0036>] do_irq+0x64/0x96\n[ 107.320271] Code: 85a6 855e b097 ff7f 80e7 9220 b709 9002 4501 bbd9 (9002) 6097\n[ 107.320585] ---[ end trace 0000000000000000 ]---\n[ 107.320704] Kernel panic - not syncing: Fatal exception in interrupt\n[ 107.320775] SMP: stopping secondary CPUs\n[ 107.321219] Kernel Offset: 0x0 from 0xffffffff80000000\n[ 107.333051] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nvhost-vdpa: fix use after free in vhost_vdpa_probe()\n\nThe put_device() calls vhost_vdpa_release_dev() which calls\nida_simple_remove() and frees "v". So this call to\nida_simple_remove() is a use after free and a double free.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal: intel: powerclamp: fix mismatch in get function for max_idle\n\nKASAN reported this\n\n [ 444.853098] BUG: KASAN: global-out-of-bounds in param_get_int+0x77/0x90\n [ 444.853111] Read of size 4 at addr ffffffffc16c9220 by task cat/2105\n ...\n [ 444.853442] The buggy address belongs to the variable:\n [ 444.853443] max_idle+0x0/0xffffffffffffcde0 [intel_powerclamp]\n\nThere is a mismatch between the param_get_int and the definition of\nmax_idle. Replacing param_get_int with param_get_byte resolves this\nissue.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Do not try to cleanup after cxl_region_setup_targets() fails\n\nCommit 5e42bcbc3fef ("cxl/region: decrement ->nr_targets on error in\ncxl_region_attach()") tried to avoid 'eiw' initialization errors when\n->nr_targets exceeded 16, by just decrementing ->nr_targets when\ncxl_region_setup_targets() failed.\n\nCommit 86987c766276 ("cxl/region: Cleanup target list on attach error")\nextended that cleanup to also clear cxled->pos and p->targets[pos]. The\ninitialization error was incidentally fixed separately by:\nCommit 8d4285425714 ("cxl/region: Fix port setup uninitialized variable\nwarnings") which was merged a few days after 5e42bcbc3fef.\n\nBut now the original cleanup when cxl_region_setup_targets() fails\nprevents endpoint and switch decoder resources from being reused:\n\n1) the cleanup does not set the decoder's region to NULL, which results\n in future dpa_size_store() calls returning -EBUSY\n2) the decoder is not properly freed, which results in future commit\n errors associated with the upstream switch\n\nNow that the initialization errors were fixed separately, the proper\ncleanup for this case is to just return immediately. Then the resources\nassociated with this target get cleanup up as normal when the failed\nregion is deleted.\n\nThe ->nr_targets decrement in the error case also helped prevent\na p->targets[] array overflow, so add a new check to prevent against\nthat overflow.\n\nTested by trying to create an invalid region for a 2 switch * 2 endpoint\ntopology, and then following up with creating a valid region.

In the Linux kernel, the following vulnerability has been resolved:\n\nswiotlb: fix out-of-bounds TLB allocations with CONFIG_SWIOTLB_DYNAMIC\n\nLimit the free list length to the size of the IO TLB. Transient pool can be\nsmaller than IO_TLB_SEGSIZE, but the free list is initialized with the\nassumption that the total number of slots is a multiple of IO_TLB_SEGSIZE.\nAs a result, swiotlb_area_find_slots() may allocate slots past the end of\na transient IO TLB buffer.

In the Linux kernel, the following vulnerability has been resolved:\n\ni915/perf: Fix NULL deref bugs with drm_dbg() calls\n\nWhen i915 perf interface is not available dereferencing it will lead to\nNULL dereferences.\n\nAs returning -ENOTSUPP is pretty clear return when perf interface is not\navailable.\n\n[tursulin: added stable tag]\n(cherry picked from commit 36f27350ff745bd228ab04d7845dfbffc177a889)

In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: make sure active queue usage is held for bio_integrity_prep()\n\nblk_integrity_unregister() can come if queue usage counter isn't held\nfor one bio with integrity prepared, so this request may be completed with\ncalling profile->complete_fn, then kernel panic.\n\nAnother constraint is that bio_integrity_prep() needs to be called\nbefore bio merge.\n\nFix the issue by:\n\n- call bio_integrity_prep() with one queue usage counter grabbed reliably\n\n- call bio_integrity_prep() before bio merge

In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix racy may inline data check in dio write\n\nsyzbot reports that the following warning from ext4_iomap_begin()\ntriggers as of the commit referenced below:\n\n if (WARN_ON_ONCE(ext4_has_inline_data(inode)))\n return -ERANGE;\n\nThis occurs during a dio write, which is never expected to encounter\nan inode with inline data. To enforce this behavior,\next4_dio_write_iter() checks the current inline state of the inode\nand clears the MAY_INLINE_DATA state flag to either fall back to\nbuffered writes, or enforce that any other writers in progress on\nthe inode are not allowed to create inline data.\n\nThe problem is that the check for existing inline data and the state\nflag can span a lock cycle. For example, if the ilock is originally\nlocked shared and subsequently upgraded to exclusive, another writer\nmay have reacquired the lock and created inline data before the dio\nwrite task acquires the lock and proceeds.\n\nThe commit referenced below loosens the lock requirements to allow\nsome forms of unaligned dio writes to occur under shared lock, but\nAFAICT the inline data check was technically already racy for any\ndio write that would have involved a lock cycle. Regardless, lift\nclearing of the state bit to the same lock critical section that\nchecks for preexisting inline data on the inode to close the race.

In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR\n\nIf command timeout happens and cq complete IRQ is raised at the same time,\nufshcd_mcq_abort clears lprb->cmd and a NULL pointer deref happens in the\nISR. Error log:\n\nufshcd_abort: Device abort task at tag 18\nUnable to handle kernel NULL pointer dereference at virtual address\n0000000000000108\npc : [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44\nlr : [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24/0x114

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wangxun: fix kernel panic due to null pointer\n\nWhen the device uses a custom subsystem vendor ID, the function\nwx_sw_init() returns before the memory of 'wx->mac_table' is allocated.\nThe null pointer will causes the kernel panic.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Track xmit submission to PTP WQ after populating metadata map\n\nEnsure the skb is available in metadata mapping to skbs before tracking the\nmetadata index for detecting undelivered CQEs. If the metadata index is put\nin the tracking list before putting the skb in the map, the metadata index\nmight be used for detecting undelivered CQEs before the relevant skb is\navailable in the map, which can lead to a null-ptr-deref.\n\nLog:\n general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n CPU: 0 PID: 1243 Comm: kworker/0:2 Not tainted 6.6.0-rc4+ #108\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Workqueue: events mlx5e_rx_dim_work [mlx5_core]\n RIP: 0010:mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core]\n Code: 8c 24 38 cc ff ff 4c 8d 3c c1 4c 89 f9 48 c1 e9 03 42 80 3c 31 00 0f 85 97 0f 00 00 4d 8b 3f 49 8d 7f 28 48 89 f9 48 c1 e9 03 <42> 80 3c 31 00 0f 85 8b 0f 00 00 49 8b 47 28 48 85 c0 0f 84 05 07\n RSP: 0018:ffff8884d3c09c88 EFLAGS: 00010206\n RAX: 0000000000000069 RBX: ffff8881160349d8 RCX: 0000000000000005\n RDX: ffffed10218f48cf RSI: 0000000000000004 RDI: 0000000000000028\n RBP: ffff888122707700 R08: 0000000000000001 R09: ffffed109a781383\n R10: 0000000000000003 R11: 0000000000000003 R12: ffff88810c7a7a40\n R13: ffff888122707700 R14: dffffc0000000000 R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff8884d3c00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f4f878dd6e0 CR3: 000000014d108002 CR4: 0000000000370eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <IRQ>\n ? die_addr+0x3c/0xa0\n ? exc_general_protection+0x144/0x210\n ? asm_exc_general_protection+0x22/0x30\n ? mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core]\n ? mlx5e_ptp_napi_poll+0x8f6/0x2290 [mlx5_core]\n __napi_poll.constprop.0+0xa4/0x580\n net_rx_action+0x460/0xb80\n ? _raw_spin_unlock_irqrestore+0x32/0x60\n ? __napi_poll.constprop.0+0x580/0x580\n ? tasklet_action_common.isra.0+0x2ef/0x760\n __do_softirq+0x26c/0x827\n irq_exit_rcu+0xc2/0x100\n common_interrupt+0x7f/0xa0\n </IRQ>\n <TASK>\n asm_common_interrupt+0x22/0x40\n RIP: 0010:__kmem_cache_alloc_node+0xb/0x330\n Code: 41 5d 41 5e 41 5f c3 8b 44 24 14 8b 4c 24 10 09 c8 eb d5 e8 b7 43 ca 01 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 <41> 56 41 89 d6 41 55 41 89 f5 41 54 49 89 fc 53 48 83 e4 f0 48 83\n RSP: 0018:ffff88812c4079c0 EFLAGS: 00000246\n RAX: 1ffffffff083c7fe RBX: ffff888100042dc0 RCX: 0000000000000218\n RDX: 00000000ffffffff RSI: 0000000000000dc0 RDI: ffff888100042dc0\n RBP: ffff88812c4079c8 R08: ffffffffa0289f96 R09: ffffed1025880ea9\n R10: ffff888138839f80 R11: 0000000000000002 R12: 0000000000000dc0\n R13: 0000000000000100 R14: 000000000000008c R15: ffff8881271fc450\n ? cmd_exec+0x796/0x2200 [mlx5_core]\n kmalloc_trace+0x26/0xc0\n cmd_exec+0x796/0x2200 [mlx5_core]\n mlx5_cmd_do+0x22/0xc0 [mlx5_core]\n mlx5_cmd_exec+0x17/0x30 [mlx5_core]\n mlx5_core_modify_cq_moderation+0x139/0x1b0 [mlx5_core]\n ? mlx5_add_cq_to_tasklet+0x280/0x280 [mlx5_core]\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? process_one_work+0x659/0x1220\n mlx5e_rx_dim_work+0x9d/0x100 [mlx5_core]\n process_one_work+0x730/0x1220\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? max_active_store+0xf0/0xf0\n ? assign_work+0x168/0x240\n worker_thread+0x70f/0x12d0\n ? __kthread_parkme+0xd1/0x1d0\n ? process_one_work+0x1220/0x1220\n kthread+0x2d9/0x3b0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x2d/0x70\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork_asm+0x11/0x20\n </TASK>\n Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay mlx5_ib ib_uverbs ib_core zram zsmalloc mlx5_core fuse\n ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mvneta: fix calls to page_pool_get_stats\n\nCalling page_pool_get_stats in the mvneta driver without checks\nleads to kernel crashes.\nFirst the page pool is only available if the bm is not used.\nThe page pool is also not allocated when the port is stopped.\nIt can also be not allocated in case of errors.\n\nThe current implementation leads to the following crash calling\nethstats on a port that is down or when calling it at the wrong moment:\n\nble to handle kernel NULL pointer dereference at virtual address 00000070\n[00000070] *pgd=00000000\nInternal error: Oops: 5 [#1] SMP ARM\nHardware name: Marvell Armada 380/385 (Device Tree)\nPC is at page_pool_get_stats+0x18/0x1cc\nLR is at mvneta_ethtool_get_stats+0xa0/0xe0 [mvneta]\npc : [<c0b413cc>] lr : [<bf0a98d8>] psr: a0000013\nsp : f1439d48 ip : f1439dc0 fp : 0000001d\nr10: 00000100 r9 : c4816b80 r8 : f0d75150\nr7 : bf0b400c r6 : c238f000 r5 : 00000000 r4 : f1439d68\nr3 : c2091040 r2 : ffffffd8 r1 : f1439d68 r0 : 00000000\nFlags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none\nControl: 10c5387d Table: 066b004a DAC: 00000051\nRegister r0 information: NULL pointer\nRegister r1 information: 2-page vmalloc region starting at 0xf1438000 allocated at kernel_clone+0x9c/0x390\nRegister r2 information: non-paged memory\nRegister r3 information: slab kmalloc-2k start c2091000 pointer offset 64 size 2048\nRegister r4 information: 2-page vmalloc region starting at 0xf1438000 allocated at kernel_clone+0x9c/0x390\nRegister r5 information: NULL pointer\nRegister r6 information: slab kmalloc-cg-4k start c238f000 pointer offset 0 size 4096\nRegister r7 information: 15-page vmalloc region starting at 0xbf0a8000 allocated at load_module+0xa30/0x219c\nRegister r8 information: 1-page vmalloc region starting at 0xf0d75000 allocated at ethtool_get_stats+0x138/0x208\nRegister r9 information: slab task_struct start c4816b80 pointer offset 0\nRegister r10 information: non-paged memory\nRegister r11 information: non-paged memory\nRegister r12 information: 2-page vmalloc region starting at 0xf1438000 allocated at kernel_clone+0x9c/0x390\nProcess snmpd (pid: 733, stack limit = 0x38de3a88)\nStack: (0xf1439d48 to 0xf143a000)\n9d40: 000000c0 00000001 c238f000 bf0b400c f0d75150 c4816b80\n9d60: 00000100 bf0a98d8 00000000 00000000 00000000 00000000 00000000 00000000\n9d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n9da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n9dc0: 00000dc0 5335509c 00000035 c238f000 bf0b2214 01067f50 f0d75000 c0b9b9c8\n9de0: 0000001d 00000035 c2212094 5335509c c4816b80 c238f000 c5ad6e00 01067f50\n9e00: c1b0be80 c4816b80 00014813 c0b9d7f0 00000000 00000000 0000001d 0000001d\n9e20: 00000000 00001200 00000000 00000000 c216ed90 c73943b8 00000000 00000000\n9e40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n9e60: 00000000 c0ad9034 00000000 00000000 00000000 00000000 00000000 00000000\n9e80: 00000000 00000000 00000000 5335509c c1b0be80 f1439ee4 00008946 c1b0be80\n9ea0: 01067f50 f1439ee3 00000000 00000046 b6d77ae0 c0b383f0 00008946 becc83e8\n9ec0: c1b0be80 00000051 0000000b c68ca480 c7172d00 c0ad8ff0 f1439ee3 cf600e40\n9ee0: 01600e40 32687465 00000000 00000000 00000000 01067f50 00000000 00000000\n9f00: 00000000 5335509c 00008946 00008946 00000000 c68ca480 becc83e8 c05e2de0\n9f20: f1439fb0 c03002f0 00000006 5ac3c35a c4816b80 00000006 b6d77ae0 c030caf0\n9f40: c4817350 00000014 f1439e1c 0000000c 00000000 00000051 01000000 00000014\n9f60: 00003fec f1439edc 00000001 c0372abc b6d77ae0 c0372abc cf600e40 5335509c\n9f80: c21e6800 01015c9c 0000000b 00008946 00000036 c03002f0 c4816b80 00000036\n9fa0: b6d77ae0 c03000c0 01015c9c 0000000b 0000000b 00008946 becc83e8 00000000\n9fc0: 01015c9c 0000000b 00008946 00000036 00000035 010678a0 b6d797ec b6d77ae0\n9fe0: b6dbf738 becc838c b6d186d7 b6baa858 40000030 0000000b 00000000 00000000\n page_pool_get_stats from mvneta_ethtool_get_stats+0xa0/0xe0 [mvneta]\n mvneta_ethtool_get_stats [mvneta] from ethtool_get_stats+0x154/0x208\n ethtool_get_stats from dev_ethtool+0xf48/0x2480\n dev_ethtool from dev_ioctl+0x538/0x63c\n dev_ioctl from sock_ioctl+0x49c/0x53c\n sock_ioctl from sys_ioctl+0x134/0xbd8\n sys_ioctl from ret_fast_syscall+0x0/0x1c\nException stack(0xf1439fa8 to 0xf1439ff0)\n9fa0: 01015c9c 0000000b 0000000b 00008946 becc83e8 00000000\n9fc0: 01015c9c 0000000b 00008946 00000036 00000035 010678a0 b6d797ec b6d77ae0\n9fe0: b6dbf738 becc838c b6d186d7 b6baa858\nCode: e28dd004 e1a05000 e2514000 0a00006a (e5902070)\n\nThis commit adds the proper checks before calling page_pool_get_stats.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs: Pass AT_GETATTR_NOSEC flag to getattr interface function\n\nWhen vfs_getattr_nosec() calls a filesystem's getattr interface function\nthen the 'nosec' should propagate into this function so that\nvfs_getattr_nosec() can again be called from the filesystem's gettattr\nrather than vfs_getattr(). The latter would add unnecessary security\nchecks that the initial vfs_getattr_nosec() call wanted to avoid.\nTherefore, introduce the getattr flag GETATTR_NOSEC and allow to pass\nwith the new getattr_flags parameter to the getattr interface function.\nIn overlayfs and ecryptfs use this flag to determine which one of the\ntwo functions to call.\n\nIn a recent code change introduced to IMA vfs_getattr_nosec() ended up\ncalling vfs_getattr() in overlayfs, which in turn called\nsecurity_inode_getattr() on an exiting process that did not have\ncurrent->fs set anymore, which then caused a kernel NULL pointer\ndereference. With this change the call to security_inode_getattr() can\nbe avoided, thus avoiding the NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: deal with large GSO size\n\nAfter the blamed commit below, the TCP sockets (and the MPTCP subflows)\ncan build egress packets larger than 64K. That exceeds the maximum DSS\ndata size, the length being misrepresent on the wire and the stream being\ncorrupted, as later observed on the receiver:\n\n WARNING: CPU: 0 PID: 9696 at net/mptcp/protocol.c:705 __mptcp_move_skbs_from_subflow+0x2604/0x26e0\n CPU: 0 PID: 9696 Comm: syz-executor.7 Not tainted 6.6.0-rc5-gcd8bdf563d46 #45\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\n netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.\n RIP: 0010:__mptcp_move_skbs_from_subflow+0x2604/0x26e0 net/mptcp/protocol.c:705\n RSP: 0018:ffffc90000006e80 EFLAGS: 00010246\n RAX: ffffffff83e9f674 RBX: ffff88802f45d870 RCX: ffff888102ad0000\n netlink: 8 bytes leftover after parsing attributes in process `syz-executor.4'.\n RDX: 0000000080000303 RSI: 0000000000013908 RDI: 0000000000003908\n RBP: ffffc90000007110 R08: ffffffff83e9e078 R09: 1ffff1100e548c8a\n R10: dffffc0000000000 R11: ffffed100e548c8b R12: 0000000000013908\n R13: dffffc0000000000 R14: 0000000000003908 R15: 000000000031cf29\n FS: 00007f239c47e700(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f239c45cd78 CR3: 000000006a66c006 CR4: 0000000000770ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600\n PKRU: 55555554\n Call Trace:\n <IRQ>\n mptcp_data_ready+0x263/0xac0 net/mptcp/protocol.c:819\n subflow_data_ready+0x268/0x6d0 net/mptcp/subflow.c:1409\n tcp_data_queue+0x21a1/0x7a60 net/ipv4/tcp_input.c:5151\n tcp_rcv_established+0x950/0x1d90 net/ipv4/tcp_input.c:6098\n tcp_v6_do_rcv+0x554/0x12f0 net/ipv6/tcp_ipv6.c:1483\n tcp_v6_rcv+0x2e26/0x3810 net/ipv6/tcp_ipv6.c:1749\n ip6_protocol_deliver_rcu+0xd6b/0x1ae0 net/ipv6/ip6_input.c:438\n ip6_input+0x1c5/0x470 net/ipv6/ip6_input.c:483\n ipv6_rcv+0xef/0x2c0 include/linux/netfilter.h:304\n __netif_receive_skb+0x1ea/0x6a0 net/core/dev.c:5532\n process_backlog+0x353/0x660 net/core/dev.c:5974\n __napi_poll+0xc6/0x5a0 net/core/dev.c:6536\n net_rx_action+0x6a0/0xfd0 net/core/dev.c:6603\n __do_softirq+0x184/0x524 kernel/softirq.c:553\n do_softirq+0xdd/0x130 kernel/softirq.c:454\n\nAddress the issue explicitly bounding the maximum GSO size to what MPTCP\nactually allows.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix dfs-radar and temperature event locking\n\nThe ath12k active pdevs are protected by RCU but the DFS-radar and\ntemperature event handling code calling ath12k_mac_get_ar_by_pdev_id()\nwas not marked as a read-side critical section.\n\nMark the code in question as RCU read-side critical sections to avoid\nany potential use-after-free issues.\n\nNote that the temperature event handler looks like a place holder\ncurrently but would still trigger an RCU lockdep splat.\n\nCompile tested only.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix a NULL pointer dereference in amdgpu_dm_i2c_xfer()\n\nWhen ddc_service_construct() is called, it explicitly checks both the\nlink type and whether there is something on the link which will\ndictate whether the pin is marked as hw_supported.\n\nIf the pin isn't set or the link is not set (such as from\nunloading/reloading amdgpu in an IGT test) then fail the\namdgpu_dm_i2c_xfer() call.

In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/port: Fix delete_endpoint() vs parent unregistration race\n\nThe CXL subsystem, at cxl_mem ->probe() time, establishes a lineage of\nports (struct cxl_port objects) between an endpoint and the root of a\nCXL topology. Each port including the endpoint port is attached to the\ncxl_port driver.\n\nGiven that setup, it follows that when either any port in that lineage\ngoes through a cxl_port ->remove() event, or the memdev goes through a\ncxl_mem ->remove() event. The hierarchy below the removed port, or the\nentire hierarchy if the memdev is removed needs to come down.\n\nThe delete_endpoint() callback is careful to check whether it is being\ncalled to tear down the hierarchy, or if it is only being called to\nteardown the memdev because an ancestor port is going through\n->remove().\n\nThat care needs to take the device_lock() of the endpoint's parent.\nWhich requires 2 bugs to be fixed:\n\n1/ A reference on the parent is needed to prevent use-after-free\n scenarios like this signature:\n\n BUG: spinlock bad magic on CPU#0, kworker/u56:0/11\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023\n Workqueue: cxl_port detach_memdev [cxl_core]\n RIP: 0010:spin_bug+0x65/0xa0\n Call Trace:\n do_raw_spin_lock+0x69/0xa0\n __mutex_lock+0x695/0xb80\n delete_endpoint+0xad/0x150 [cxl_core]\n devres_release_all+0xb8/0x110\n device_unbind_cleanup+0xe/0x70\n device_release_driver_internal+0x1d2/0x210\n detach_memdev+0x15/0x20 [cxl_core]\n process_one_work+0x1e3/0x4c0\n worker_thread+0x1dd/0x3d0\n\n2/ In the case of RCH topologies, the parent device that needs to be\n locked is not always @port->dev as returned by cxl_mem_find_port(), use\n endpoint->dev.parent instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: split initial and dynamic conditions for extent_cache\n\nLet's allocate the extent_cache tree without dynamic conditions to avoid a\nmissing condition causing a panic as below.\n\n # create a file w/ a compressed flag\n # disable the compression\n # panic while updating extent_cache\n\nF2FS-fs (dm-64): Swapfile: last extent is not aligned to section\nF2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N)\nAdding 124996k swap on ./swap-file. Priority:0 extents:2 across:17179494468k\n==================================================================\nBUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline]\nBUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline]\nBUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline]\nBUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline]\nBUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295\nWrite of size 4 at addr 0000000000000030 by task syz-executor154/3327\n\nCPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G O 5.10.185 #1\nHardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023\nCall Trace:\n __dump_stack out/common/lib/dump_stack.c:77 [inline]\n dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118\n __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415\n kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428\n kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186\n __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37\n instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline]\n atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline]\n queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline]\n __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline]\n _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295\n __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155\n f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172\n f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline]\n f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764\n vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310\n ksys_fallocate out/common/fs/open.c:333 [inline]\n __do_sys_fallocate out/common/fs/open.c:341 [inline]\n __se_sys_fallocate out/common/fs/open.c:339 [inline]\n __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339\n do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix htt mlo-offset event locking\n\nThe ath12k active pdevs are protected by RCU but the htt mlo-offset\nevent handling code calling ath12k_mac_get_ar_by_pdev_id() was not\nmarked as a read-side critical section.\n\nMark the code in question as an RCU read-side critical section to avoid\nany potential use-after-free issues.\n\nCompile tested only.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: use vmm_table as array in wilc struct\n\nEnabling KASAN and running some iperf tests raises some memory issues with\nvmm_table:\n\nBUG: KASAN: slab-out-of-bounds in wilc_wlan_handle_txq+0x6ac/0xdb4\nWrite of size 4 at addr c3a61540 by task wlan0-tx/95\n\nKASAN detects that we are writing data beyond range allocated to vmm_table.\nThere is indeed a mismatch between the size passed to allocator in\nwilc_wlan_init, and the range of possible indexes used later: allocation\nsize is missing a multiplication by sizeof(u32)

In the Linux kernel, the following vulnerability has been resolved:\n\ntls: fix NULL deref on tls_sw_splice_eof() with empty record\n\nsyzkaller discovered that if tls_sw_splice_eof() is executed as part of\nsendfile() when the plaintext/ciphertext sk_msg are empty, the send path\ngets confused because the empty ciphertext buffer does not have enough\nspace for the encryption overhead. This causes tls_push_record() to go on\nthe `split = true` path (which is only supposed to be used when interacting\nwith an attached BPF program), and then get further confused and hit the\ntls_merge_open_record() path, which then assumes that there must be at\nleast one populated buffer element, leading to a NULL deref.\n\nIt is possible to have empty plaintext/ciphertext buffers if we previously\nbailed from tls_sw_sendmsg_locked() via the tls_trim_both_msgs() path.\ntls_sw_push_pending_record() already handles this case correctly; let's do\nthe same check in tls_sw_splice_eof().

In the Linux kernel, the following vulnerability has been resolved:\n\nmfd: qcom-spmi-pmic: Fix revid implementation\n\nThe Qualcomm SPMI PMIC revid implementation is broken in multiple ways.\n\nFirst, it assumes that just because the sibling base device has been\nregistered that means that it is also bound to a driver, which may not\nbe the case (e.g. due to probe deferral or asynchronous probe). This\ncould trigger a NULL-pointer dereference when attempting to access the\ndriver data of the unbound device.\n\nSecond, it accesses driver data of a sibling device directly and without\nany locking, which means that the driver data may be freed while it is\nbeing accessed (e.g. on driver unbind).\n\nThird, it leaks a struct device reference to the sibling device which is\nlooked up using the spmi_device_from_of() every time a function (child)\ndevice is calling the revid function (e.g. on probe).\n\nFix this mess by reimplementing the revid lookup so that it is done only\nat probe of the PMIC device; the base device fetches the revid info from\nthe hardware, while any secondary SPMI device fetches the information\nfrom the base device and caches it so that it can be accessed safely\nfrom its children. If the base device has not been probed yet then probe\nof a secondary device is deferred.

In the Linux kernel, the following vulnerability has been resolved:\n\nIB/IPoIB: Fix legacy IPoIB due to wrong number of queues\n\nThe cited commit creates child PKEY interfaces over netlink will\nmultiple tx and rx queues, but some devices doesn't support more than 1\ntx and 1 rx queues. This causes to a crash when traffic is sent over the\nPKEY interface due to the parent having a single queue but the child\nhaving multiple queues.\n\nThis patch fixes the number of queues to 1 for legacy IPoIB at the\nearliest possible point in time.\n\nBUG: kernel NULL pointer dereference, address: 000000000000036b\nPGD 0 P4D 0\nOops: 0000 [#1] SMP\nCPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kmem_cache_alloc+0xcb/0x450\nCode: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a\n01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b\nRSP: 0018:ffff88822acbbab8 EFLAGS: 00010202\nRAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae\nRDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00\nRBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40\nR10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000\nR13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000\nFS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n skb_clone+0x55/0xd0\n ip6_finish_output2+0x3fe/0x690\n ip6_finish_output+0xfa/0x310\n ip6_send_skb+0x1e/0x60\n udp_v6_send_skb+0x1e5/0x420\n udpv6_sendmsg+0xb3c/0xe60\n ? ip_mc_finish_output+0x180/0x180\n ? __switch_to_asm+0x3a/0x60\n ? __switch_to_asm+0x34/0x60\n sock_sendmsg+0x33/0x40\n __sys_sendto+0x103/0x160\n ? _copy_to_user+0x21/0x30\n ? kvm_clock_get_cycles+0xd/0x10\n ? ktime_get_ts64+0x49/0xe0\n __x64_sys_sendto+0x25/0x30\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7f9374f1ed14\nCode: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b\n7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b\nRSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14\nRDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030\nRBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\nR13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc\n </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix potential NULL-ptr-dereference\n\nin_dev_get() can return NULL which will cause a failure once idev is\ndereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a\ncheck for NULL value in idev beforehand.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: USB: Fix wrong-direction WARNING in plusb.c\n\nThe syzbot fuzzer detected a bug in the plusb network driver: A\nzero-length control-OUT transfer was treated as a read instead of a\nwrite. In modern kernels this error provokes a WARNING:\n\nusb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0\nWARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411\nusb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\nModules linked in:\nCPU: 1 PID: 4645 Comm: dhcpcd Not tainted\n6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n01/12/2023\nRIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\n...\nCall Trace:\n <TASK>\n usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58\n usb_internal_control_msg drivers/usb/core/message.c:102 [inline]\n usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153\n __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010\n usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068\n pl_vendor_req drivers/net/usb/plusb.c:60 [inline]\n pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]\n pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85\n usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889\n __dev_open+0x297/0x4d0 net/core/dev.c:1417\n __dev_change_flags+0x587/0x750 net/core/dev.c:8530\n dev_change_flags+0x97/0x170 net/core/dev.c:8602\n devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147\n inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979\n sock_do_ioctl+0xcc/0x230 net/socket.c:1169\n sock_ioctl+0x1f8/0x680 net/socket.c:1286\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+0x197/0x210 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and\nremove the USB_DIR_IN flag.

In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix use-after-free in rdata->read_into_pages()\n\nWhen the network status is unstable, use-after-free may occur when\nread data from the server.\n\n BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0\n\n Call Trace:\n <TASK>\n dump_stack_lvl+0x38/0x4c\n print_report+0x16f/0x4a6\n kasan_report+0xb7/0x130\n readpages_fill_pages+0x14c/0x7e0\n cifs_readv_receive+0x46d/0xa40\n cifs_demultiplex_thread+0x121c/0x1490\n kthread+0x16b/0x1a0\n ret_from_fork+0x2c/0x50\n </TASK>\n\n Allocated by task 2535:\n kasan_save_stack+0x22/0x50\n kasan_set_track+0x25/0x30\n __kasan_kmalloc+0x82/0x90\n cifs_readdata_direct_alloc+0x2c/0x110\n cifs_readdata_alloc+0x2d/0x60\n cifs_readahead+0x393/0xfe0\n read_pages+0x12f/0x470\n page_cache_ra_unbounded+0x1b1/0x240\n filemap_get_pages+0x1c8/0x9a0\n filemap_read+0x1c0/0x540\n cifs_strict_readv+0x21b/0x240\n vfs_read+0x395/0x4b0\n ksys_read+0xb8/0x150\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\n Freed by task 79:\n kasan_save_stack+0x22/0x50\n kasan_set_track+0x25/0x30\n kasan_save_free_info+0x2e/0x50\n __kasan_slab_free+0x10e/0x1a0\n __kmem_cache_free+0x7a/0x1a0\n cifs_readdata_release+0x49/0x60\n process_one_work+0x46c/0x760\n worker_thread+0x2a4/0x6f0\n kthread+0x16b/0x1a0\n ret_from_fork+0x2c/0x50\n\n Last potentially related work creation:\n kasan_save_stack+0x22/0x50\n __kasan_record_aux_stack+0x95/0xb0\n insert_work+0x2b/0x130\n __queue_work+0x1fe/0x660\n queue_work_on+0x4b/0x60\n smb2_readv_callback+0x396/0x800\n cifs_abort_connection+0x474/0x6a0\n cifs_reconnect+0x5cb/0xa50\n cifs_readv_from_socket.cold+0x22/0x6c\n cifs_read_page_from_socket+0xc1/0x100\n readpages_fill_pages.cold+0x2f/0x46\n cifs_readv_receive+0x46d/0xa40\n cifs_demultiplex_thread+0x121c/0x1490\n kthread+0x16b/0x1a0\n ret_from_fork+0x2c/0x50\n\nThe following function calls will cause UAF of the rdata pointer.\n\nreadpages_fill_pages\n cifs_read_page_from_socket\n cifs_readv_from_socket\n cifs_reconnect\n __cifs_reconnect\n cifs_abort_connection\n mid->callback() --> smb2_readv_callback\n queue_work(&rdata->work) # if the worker completes first,\n # the rdata is freed\n cifs_readv_complete\n kref_put\n cifs_readdata_release\n kfree(rdata)\n return rdata->... # UAF in readpages_fill_pages()\n\nSimilarly, this problem also occurs in the uncache_fill_pages().\n\nFix this by adjusts the order of condition judgment in the return\nstatement.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini\n\nCurrently amdgpu calls drm_sched_fini() from the fence driver sw fini\nroutine - such function is expected to be called only after the\nrespective init function - drm_sched_init() - was executed successfully.\n\nHappens that we faced a driver probe failure in the Steam Deck\nrecently, and the function drm_sched_fini() was called even without\nits counter-part had been previously called, causing the following oops:\n\namdgpu: probe of 0000:04:00.0 failed with error -110\nBUG: kernel NULL pointer dereference, address: 0000000000000090\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338\nHardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022\nRIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]\n[...]\nCall Trace:\n <TASK>\n amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]\n amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]\n amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n devm_drm_dev_init_release+0x49/0x70\n [...]\n\nTo prevent that, check if the drm_sched was properly initialized for a\ngiven ring before calling its fini counter-part.\n\nNotice ideally we'd use sched.ready for that; such field is set as the latest\nthing on drm_sched_init(). But amdgpu seems to "override" the meaning of such\nfield - in the above oops for example, it was a GFX ring causing the crash, and\nthe sched.ready field was set to true in the ring init routine, regardless of\nthe state of the DRM scheduler. Hence, we ended-up using sched.ops as per\nChristian's suggestion [0], and also removed the no_scheduler check [1].\n\n[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/\n[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/

In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix invalid page access after closing deferred I/O devices\n\nWhen a fbdev with deferred I/O is once opened and closed, the dirty\npages still remain queued in the pageref list, and eventually later\nthose may be processed in the delayed work. This may lead to a\ncorruption of pages, hitting an Oops.\n\nThis patch makes sure to cancel the delayed work and clean up the\npageref list at closing the device for addressing the bug. A part of\nthe cleanup code is factored out as a new helper function that is\ncalled from the common fb_release().

In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: mmc_spi: fix error handling in mmc_spi_probe()\n\nIf mmc_add_host() fails, it doesn't need to call mmc_remove_host(),\nor it will cause null-ptr-deref, because of deleting a not added\ndevice in mmc_remove_host().\n\nTo fix this, goto label 'fail_glue_init', if mmc_add_host() fails,\nand change the label 'fail_add_host' to 'fail_gpiod_request'.

In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: sim: fix a memory leak\n\nFix an inverted logic bug in gpio_sim_remove_hogs() that leads to GPIO\nhog structures never being freed.

In the Linux kernel, the following vulnerability has been resolved:\n\nfreezer,umh: Fix call_usermode_helper_exec() vs SIGKILL\n\nTetsuo-San noted that commit f5d39b020809 ("freezer,sched: Rewrite\ncore freezer logic") broke call_usermodehelper_exec() for the KILLABLE\ncase.\n\nSpecifically it was missed that the second, unconditional,\nwait_for_completion() was not optional and ensures the on-stack\ncompletion is unused before going out-of-scope.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Check writeback connectors in create_validate_stream_for_sink\n\n[WHY & HOW]\nThis is to check connector type to avoid\nunhandled null pointer for writeback connectors.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: scarlett2: Add missing error check to scarlett2_usb_set_config()\n\nscarlett2_usb_set_config() calls scarlett2_usb_get() but was not\nchecking the result. Return the error if it fails rather than\ncontinuing with an invalid value.

In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: scarlett2: Add missing mutex lock around get meter levels\n\nAs scarlett2_meter_ctl_get() uses meter_level_map[], the data_mutex\nshould be locked while accessing it.

In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: safexcel - Add error handling for dma_map_sg() calls\n\nMacro dma_map_sg() may return 0 on error. This patch enables\nchecks in case of the macro failure and ensures unmapping of\npreviously mapped buffers with dma_unmap_sg().\n\nFound by Linux Verification Center (linuxtesting.org) with static\nanalysis tool SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: qseecom: fix memory leaks in error paths\n\nFix instances of returning error codes directly instead of jumping to\nthe relevant labels where memory allocated for the SCM calls would be\nfreed.

In the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: Free s_fs_info on unmount\n\nNow that we allocate a s_fs_info struct on fs context creation, we\nshould ensure that we free it again when the superblock goes away.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c\n\nBefore using list_first_entry, make sure to check that list is not\nempty, if list is empty return -ENODATA.\n\nFixes the below:\ndrivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL?\ndrivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL?\ndrivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?