In the Linux kernel, the following vulnerability has been resolved:\n\nblock: refine the EOF check in blkdev_iomap_begin\n\nblkdev_iomap_begin rounds down the offset to the logical block size\nbefore stashing it in iomap->offset and checking that it still is\ninside the inode size.\n\nCheck the i_size check to the raw pos value so that we don't try a\nzero size write if iter->pos is unaligned.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()\n\npci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()\nfails, the irq vector is not freed, which leads to a memory leak.\n\nReplace the devm_add_action with devm_add_action_or_reset to ensure\nthe irq vector can be destroyed when it fails.

In the Linux kernel, the following vulnerability has been resolved:\n\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\n\nErhard reports netpoll warnings from sungem:\n\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\n\ngem_poll_controller() disables interrupts, which may sleep.\nWe can't sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn't even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix peer devlink set for SF representor devlink port\n\nThe cited patch change register devlink flow, and neglect to reflect\nthe changes for peer devlink set logic. Peer devlink set is\ntriggering a call trace if done after devl_register.[1]\n\nHence, align peer devlink set logic with register devlink flow.\n\n[1]\nWARNING: CPU: 4 PID: 3394 at net/devlink/core.c:155 devlink_rel_nested_in_add+0x177/0x180\nCPU: 4 PID: 3394 Comm: kworker/u40:1 Not tainted 6.9.0-rc4_for_linust_min_debug_2024_04_16_14_08 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nWorkqueue: mlx5_vhca_event0 mlx5_vhca_state_work_handler [mlx5_core]\nRIP: 0010:devlink_rel_nested_in_add+0x177/0x180\nCall Trace:\n <TASK>\n ? __warn+0x78/0x120\n ? devlink_rel_nested_in_add+0x177/0x180\n ? report_bug+0x16d/0x180\n ? handle_bug+0x3c/0x60\n ? exc_invalid_op+0x14/0x70\n ? asm_exc_invalid_op+0x16/0x20\n ? devlink_port_init+0x30/0x30\n ? devlink_port_type_clear+0x50/0x50\n ? devlink_rel_nested_in_add+0x177/0x180\n ? devlink_rel_nested_in_add+0xdd/0x180\n mlx5_sf_mdev_event+0x74/0xb0 [mlx5_core]\n notifier_call_chain+0x35/0xb0\n blocking_notifier_call_chain+0x3d/0x60\n mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]\n mlx5_sf_dev_probe+0x185/0x3e0 [mlx5_core]\n auxiliary_bus_probe+0x38/0x80\n ? driver_sysfs_add+0x51/0x80\n really_probe+0xc5/0x3a0\n ? driver_probe_device+0x90/0x90\n __driver_probe_device+0x80/0x160\n driver_probe_device+0x1e/0x90\n __device_attach_driver+0x7d/0x100\n bus_for_each_drv+0x80/0xd0\n __device_attach+0xbc/0x1f0\n bus_probe_device+0x86/0xa0\n device_add+0x64f/0x860\n __auxiliary_device_add+0x3b/0xa0\n mlx5_sf_dev_add+0x139/0x330 [mlx5_core]\n mlx5_sf_dev_state_change_handler+0x1e4/0x250 [mlx5_core]\n notifier_call_chain+0x35/0xb0\n blocking_notifier_call_chain+0x3d/0x60\n mlx5_vhca_state_work_handler+0x151/0x200 [mlx5_core]\n process_one_work+0x13f/0x2e0\n worker_thread+0x2bd/0x3c0\n ? rescuer_thread+0x410/0x410\n kthread+0xc4/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x2d/0x50\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork_asm+0x11/0x20\n </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: micrel: Fix receiving the timestamp in the frame for lan8841\n\nThe blamed commit started to use the ptp workqueue to get the second\npart of the timestamp. And when the port was set down, then this\nworkqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING\nis not enabled, then the ptp_clock is not initialized so then it would\ncrash when it would try to access the delayed work.\nSo then basically by setting up and then down the port, it would crash.\nThe fix consists in checking if the ptp_clock is initialized and only\nthen cancel the delayed work.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Init `ddp_comp` with devm_kcalloc()\n\nIn the case where `conn_routes` is true we allocate an extra slot in\nthe `ddp_comp` array but mtk_drm_crtc_create() never seemed to\ninitialize it in the test case I ran. For me, this caused a later\ncrash when we looped through the array in mtk_drm_crtc_mode_valid().\nThis showed up for me when I booted with `slub_debug=FZPUA` which\npoisons the memory initially. Without `slub_debug` I couldn't\nreproduce, presumably because the later code handles the value being\nNULL and in most cases (not guaranteed in all cases) the memory the\nallocator returned started out as 0.\n\nIt really doesn't hurt to initialize the array with devm_kcalloc()\nsince the array is small and the overhead of initting a handful of\nelements to 0 is small. In general initting memory to zero is a safer\npractice and usually it's suggested to only use the non-initting alloc\nfunctions if you really need to.\n\nLet's switch the function to use an allocation function that zeros the\nmemory. For me, this avoids the crash.

In the Linux kernel, the following vulnerability has been resolved:\n\nspeakup: Fix sizeof() vs ARRAY_SIZE() bug\n\nThe "buf" pointer is an array of u16 values. This code should be\nusing ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512),\notherwise it can the still got out of bounds.

In the Linux kernel, the following vulnerability has been resolved:\n\ntools/nolibc/stdlib: fix memory error in realloc()\n\nPass user_p_len to memcpy() instead of heap->len to prevent realloc()\nfrom copying an extra sizeof(heap) bytes from beyond the allocated\nregion.

In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix use-after-free of timer for log writer thread\n\nPatch series "nilfs2: fix log writer related issues".\n\nThis bug fix series covers three nilfs2 log writer-related issues,\nincluding a timer use-after-free issue and potential deadlock issue on\nunmount, and a potential freeze issue in event synchronization found\nduring their analysis. Details are described in each commit log.\n\n\nThis patch (of 3):\n\nA use-after-free issue has been reported regarding the timer sc_timer on\nthe nilfs_sc_info structure.\n\nThe problem is that even though it is used to wake up a sleeping log\nwriter thread, sc_timer is not shut down until the nilfs_sc_info structure\nis about to be freed, and is used regardless of the thread's lifetime.\n\nFix this issue by limiting the use of sc_timer only while the log writer\nthread is alive.

In the Linux kernel, the following vulnerability has been resolved:\n\necryptfs: Fix buffer size for tag 66 packet\n\nThe 'TAG 66 Packet Format' description is missing the cipher code and\nchecksum fields that are packed into the message packet. As a result,\nthe buffer allocated for the packet is 3 bytes too small and\nwrite_tag_66_packet() will write up to 3 bytes past the end of the\nbuffer.\n\nFix this by increasing the size of the allocation so the whole packet\nwill always fit in the buffer.\n\nThis fixes the below kasan slab-out-of-bounds bug:\n\n BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0\n Write of size 1 at addr ffff88800afbb2a5 by task touch/181\n\n CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014\n Call Trace:\n <TASK>\n dump_stack_lvl+0x4c/0x70\n print_report+0xc5/0x610\n ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n ? kasan_complete_mode_report_info+0x44/0x210\n ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n kasan_report+0xc2/0x110\n ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n __asan_store1+0x62/0x80\n ecryptfs_generate_key_packet_set+0x7d6/0xde0\n ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10\n ? __alloc_pages+0x2e2/0x540\n ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]\n ? dentry_open+0x8f/0xd0\n ecryptfs_write_metadata+0x30a/0x550\n ? __pfx_ecryptfs_write_metadata+0x10/0x10\n ? ecryptfs_get_lower_file+0x6b/0x190\n ecryptfs_initialize_file+0x77/0x150\n ecryptfs_create+0x1c2/0x2f0\n path_openat+0x17cf/0x1ba0\n ? __pfx_path_openat+0x10/0x10\n do_filp_open+0x15e/0x290\n ? __pfx_do_filp_open+0x10/0x10\n ? __kasan_check_write+0x18/0x30\n ? _raw_spin_lock+0x86/0xf0\n ? __pfx__raw_spin_lock+0x10/0x10\n ? __kasan_check_write+0x18/0x30\n ? alloc_fd+0xf4/0x330\n do_sys_openat2+0x122/0x160\n ? __pfx_do_sys_openat2+0x10/0x10\n __x64_sys_openat+0xef/0x170\n ? __pfx___x64_sys_openat+0x10/0x10\n do_syscall_64+0x60/0xd0\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n RIP: 0033:0x7f00a703fd67\n Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f\n RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101\n RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67\n RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c\n RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000\n R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941\n R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040\n </TASK>\n\n Allocated by task 181:\n kasan_save_stack+0x2f/0x60\n kasan_set_track+0x29/0x40\n kasan_save_alloc_info+0x25/0x40\n __kasan_kmalloc+0xc5/0xd0\n __kmalloc+0x66/0x160\n ecryptfs_generate_key_packet_set+0x6d2/0xde0\n ecryptfs_write_metadata+0x30a/0x550\n ecryptfs_initialize_file+0x77/0x150\n ecryptfs_create+0x1c2/0x2f0\n path_openat+0x17cf/0x1ba0\n do_filp_open+0x15e/0x290\n do_sys_openat2+0x122/0x160\n __x64_sys_openat+0xef/0x170\n do_syscall_64+0x60/0xd0\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8

In the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix buffer overflow in print_cpu_stall_info()\n\nThe rcuc-starvation output from print_cpu_stall_info() might overflow the\nbuffer if there is a huge difference in jiffies difference. The situation\nmight seem improbable, but computers sometimes get very confused about\ntime, which can result in full-sized integers, and, in this case,\nbuffer overflow.\n\nAlso, the unsigned jiffies difference is printed using %ld, which is\nnormally for signed integers. This is intentional for debugging purposes,\nbut it is not obvious from the code.\n\nThis commit therefore changes sprintf() to snprintf() and adds a\nclarifying comment about intention of %ld format.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix out-of-bound access of qmi_invoke_handler()\n\nCurrently, there is no terminator entry for ath12k_qmi_msg_handlers hence\nfacing below KASAN warning,\n\n ==================================================================\n BUG: KASAN: global-out-of-bounds in qmi_invoke_handler+0xa4/0x148\n Read of size 8 at addr ffffffd00a6428d8 by task kworker/u8:2/1273\n\n CPU: 0 PID: 1273 Comm: kworker/u8:2 Not tainted 5.4.213 #0\n Workqueue: qmi_msg_handler qmi_data_ready_work\n Call trace:\n dump_backtrace+0x0/0x20c\n show_stack+0x14/0x1c\n dump_stack+0xe0/0x138\n print_address_description.isra.5+0x30/0x330\n __kasan_report+0x16c/0x1bc\n kasan_report+0xc/0x14\n __asan_load8+0xa8/0xb0\n qmi_invoke_handler+0xa4/0x148\n qmi_handle_message+0x18c/0x1bc\n qmi_data_ready_work+0x4ec/0x528\n process_one_work+0x2c0/0x440\n worker_thread+0x324/0x4b8\n kthread+0x210/0x228\n ret_from_fork+0x10/0x18\n\n The address belongs to the variable:\n ath12k_mac_mon_status_filter_default+0x4bd8/0xfffffffffffe2300 [ath12k]\n [...]\n ==================================================================\n\nAdd a dummy terminator entry at the end to assist the qmi_invoke_handler()\nin traversing up to the terminator entry without accessing an\nout-of-boundary index.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/tsens: Fix null pointer dereference\n\ncompute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)\nas compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null\npointer dereference (if DEBUG or DYNAMIC_DEBUG set).\nFix this bug by adding null pointer check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/perf: hisi_pcie: Fix out-of-bound access when valid event group\n\nThe perf tool allows users to create event groups through following\ncmd [1], but the driver does not check whether the array index is out of\nbounds when writing data to the event_group array. If the number of events\nin an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write\noverflow of event_group array occurs.\n\nAdd array index check to fix the possible array out of bounds violation,\nand return directly when write new events are written to array bounds.\n\nThere are 9 different events in an event_group.\n[1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'

In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/perf: hisi: hns3: Fix out-of-bound access when valid event group\n\nThe perf tool allows users to create event groups through following\ncmd [1], but the driver does not check whether the array index is out\nof bounds when writing data to the event_group array. If the number of\nevents in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the\nmemory write overflow of event_group array occurs.\n\nAdd array index check to fix the possible array out of bounds violation,\nand return directly when write new events are written to array bounds.\n\nThere are 9 different events in an event_group.\n[1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: carl9170: add a proper sanity check for endpoints\n\nSyzkaller reports [1] hitting a warning which is caused by presence\nof a wrong endpoint type at the URB sumbitting stage. While there\nwas a check for a specific 4th endpoint, since it can switch types\nbetween bulk and interrupt, other endpoints are trusted implicitly.\nSimilar warning is triggered in a couple of other syzbot issues [2].\n\nFix the issue by doing a comprehensive check of all endpoints\ntaking into account difference between high- and full-speed\nconfiguration.\n\n[1] Syzkaller report:\n...\nWARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n <TASK>\n carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504\n carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]\n carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]\n carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028\n request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107\n process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289\n worker_thread+0x669/0x1090 kernel/workqueue.c:2436\n kthread+0x2e8/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n </TASK>\n\n[2] Related syzkaller crashes:

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix verifier assumptions about socket->sk\n\nThe verifier assumes that 'sk' field in 'struct socket' is valid\nand non-NULL when 'socket' pointer itself is trusted and non-NULL.\nThat may not be the case when socket was just created and\npassed to LSM socket_accept hook.\nFix this verifier assumption and adjust tests.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE\n\nbpf_prog_attach uses attach_type_to_prog_type to enforce proper\nattach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses\nbpf_prog_get and relies on bpf_prog_attach_check_attach_type\nto properly verify prog_type <> attach_type association.\n\nAdd missing attach_type enforcement for the link_create case.\nOtherwise, it's currently possible to attach cgroup_skb prog\ntypes to other cgroup hooks.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7996: fix potential memory leakage when reading chip temperature\n\nWithout this commit, reading chip temperature will cause memory leakage.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: nl80211: Avoid address calculations via out of bounds array indexing\n\nBefore request->channels[] can be used, request->n_channels must be set.\nAdditionally, address calculations for memory after the "channels" array\nneed to be calculated from the allocation base ("request") rather than\nvia the first "out of bounds" index of "channels", otherwise run-time\nbounds checking will throw a warning.

In the Linux kernel, the following vulnerability has been resolved:\n\nkunit: Fix kthread reference\n\nThere is a race condition when a kthread finishes after the deadline and\nbefore the call to kthread_stop(), which may lead to use after free.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Reload only IB representors upon lag disable/enable\n\nOn lag disable, the bond IB device along with all of its\nrepresentors are destroyed, and then the slaves' representors get reloaded.\n\nIn case the slave IB representor load fails, the eswitch error flow\nunloads all representors, including ethernet representors, where the\nnetdevs get detached and removed from lag bond. Such flow is inaccurate\nas the lag driver is not responsible for loading/unloading ethernet\nrepresentors. Furthermore, the flow described above begins by holding\nlag lock to prevent bond changes during disable flow. However, when\nreaching the ethernet representors detachment from lag, the lag lock is\nrequired again, triggering the following deadlock:\n\nCall trace:\n__switch_to+0xf4/0x148\n__schedule+0x2c8/0x7d0\nschedule+0x50/0xe0\nschedule_preempt_disabled+0x18/0x28\n__mutex_lock.isra.13+0x2b8/0x570\n__mutex_lock_slowpath+0x1c/0x28\nmutex_lock+0x4c/0x68\nmlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]\nmlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]\nmlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]\nmlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]\nmlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]\nmlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]\nmlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]\nmlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]\nmlx5_disable_lag+0x130/0x138 [mlx5_core]\nmlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock\nmlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]\ndevlink_nl_cmd_eswitch_set_doit+0xdc/0x180\ngenl_family_rcv_msg_doit.isra.17+0xe8/0x138\ngenl_rcv_msg+0xe4/0x220\nnetlink_rcv_skb+0x44/0x108\ngenl_rcv+0x40/0x58\nnetlink_unicast+0x198/0x268\nnetlink_sendmsg+0x1d4/0x418\nsock_sendmsg+0x54/0x60\n__sys_sendto+0xf4/0x120\n__arm64_sys_sendto+0x30/0x40\nel0_svc_common+0x8c/0x120\ndo_el0_svc+0x30/0xa0\nel0_svc+0x20/0x30\nel0_sync_handler+0x90/0xb8\nel0_sync+0x160/0x180\n\nThus, upon lag enable/disable, load and unload only the IB representors\nof the slaves preventing the deadlock mentioned above.\n\nWhile at it, refactor the mlx5_esw_offloads_rep_load() function to have\na static helper method for its internal logic, in symmetry with the\nrepresentor unload design.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix potential index out of bounds in color transformation function\n\nFixes index out of bounds issue in the color transformation function.\nThe issue could occur when the index 'i' exceeds the number of transfer\nfunction points (TRANSFER_FUNC_POINTS).\n\nThe fix adds a check to ensure 'i' is within bounds before accessing the\ntransfer function points. If 'i' is out of bounds, an error message is\nlogged and the function returns false to indicate an error.\n\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: Assign dummy when codec not specified for a DAI link\n\nMediaTek sound card drivers are checking whether a DAI link is present\nand used on a board to assign the correct parameters and this is done\nby checking the codec DAI names at probe time.\n\nIf no real codec is present, assign the dummy codec to the DAI link\nto avoid NULL pointer during string comparison.

In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: kirkwood: Fix potential NULL dereference\n\nIn kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if\nCONFIG_PLAT_ORION macro is not defined.\nFix this bug by adding NULL check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix seg fault in rxe_comp_queue_pkt\n\nIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the\nresp_pkts queue and then a decision is made whether to run the completer\ntask inline or schedule it. Finally the skb is dereferenced to bump a 'hw'\nperformance counter. This is wrong because if the completer task is\nalready running in a separate thread it may have already processed the skb\nand freed it which can cause a seg fault. This has been observed\ninfrequently in testing at high scale.\n\nThis patch fixes this by changing the order of enqueuing the packet until\nafter the counter is accessed.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mana_ib: boundary check before installing cq callbacks\n\nAdd a boundary check inside mana_ib_install_cq_cb to prevent index overflow.

In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw\n\nWhen running blktests nvme/rdma, the following kmemleak issue will appear.\n\nkmemleak: Kernel memory leak detector initialized (mempool available:36041)\nkmemleak: Automatic memory scanning thread started\nkmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n\nunreferenced object 0xffff88855da53400 (size 192):\n comm "rdma", pid 10630, jiffies 4296575922\n hex dump (first 32 bytes):\n 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7...............\n 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.]....\n backtrace (crc 47f66721):\n [<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0\n [<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core]\n [<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core]\n [<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core]\n [<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core]\n [<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core]\n [<ffffffffc2a3d389>] 0xffffffffc2a3d389\n [<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core]\n [<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core]\n [<ffffffffc264648c>]\nrdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core]\n [<ffffffff9270e7b5>] netlink_unicast+0x445/0x710\n [<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40\n [<ffffffff9249db29>] __sys_sendto+0x3a9/0x420\n [<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0\n [<ffffffff92db0ad3>] do_syscall_64+0x93/0x180\n [<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79\n\nThe root cause: rdma_put_gid_attr is not called when sgid_attr is set\nto ERR_PTR(-ENODEV).

A vulnerability was found in Tomcat. Under certain configurations on any platform, this flaw allows an attacker to cause an OutOfMemoryError by abusing the TLS handshake process.

.NET and Visual Studio Remote Code Execution Vulnerability

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: Wait unconditionally after issuing EndXfer command\n\nCurrently all controller IP/revisions except DWC3_usb3 >= 310a\nwait 1ms unconditionally for ENDXFER completion when IOC is not\nset. This is because DWC_usb3 controller revisions >= 3.10a\nsupports GUCTL2[14: Rst_actbitlater] bit which allows polling\nCMDACT bit to know whether ENDXFER command is completed.\n\nConsider a case where an IN request was queued, and parallelly\nsoft_disconnect was called (due to ffs_epfile_release). This\neventually calls stop_active_transfer with IOC cleared, hence\nsend_gadget_ep_cmd() skips waiting for CMDACT cleared during\nEndXfer. For DWC3 controllers with revisions >= 310a, we don't\nforcefully wait for 1ms either, and we proceed by unmapping the\nrequests. If ENDXFER didn't complete by this time, it leads to\nSMMU faults since the controller would still be accessing those\nrequests.\n\nFix this by ensuring ENDXFER completion by adding 1ms delay in\n__dwc3_stop_active_transfer() unconditionally.

In the Linux kernel, the following vulnerability has been resolved:\n\nRevert "media: v4l2-ctrls: show all owned controls in log_status"\n\nThis reverts commit 9801b5b28c6929139d6fceeee8d739cc67bb2739.\n\nThis patch introduced a potential deadlock scenario:\n\n[Wed May 8 10:02:06 2024] Possible unsafe locking scenario:\n\n[Wed May 8 10:02:06 2024] CPU0 CPU1\n[Wed May 8 10:02:06 2024] ---- ----\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock);\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock);\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock);\n[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock);\n\nFor now just revert.

In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Do not use WARN when encode fails\n\nWhen asn1_encode_sequence() fails, WARN is not the correct solution.\n\n1. asn1_encode_sequence() is not an internal function (located\n in lib/asn1_encode.c).\n2. Location is known, which makes the stack trace useless.\n3. Results a crash if panic_on_warn is set.\n\nIt is also noteworthy that the use of WARN is undocumented, and it\nshould be avoided unless there is a carefully considered rationale to\nuse it.\n\nReplace WARN with pr_err, and print the return value instead, which is\nonly useful piece of information.

In the Linux kernel, the following vulnerability has been resolved:\n\nmisc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe()\n\nWhen auxiliary_device_add() returns error and then calls\nauxiliary_device_uninit(), callback function\ngp_auxiliary_device_release() calls ida_free() and\nkfree(aux_device_wrapper) to free memory. We should't\ncall them again in the error handling path.\n\nFix this by skipping the redundant cleanup functions.

In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock.\n\nBilly Jheng Bing-Jhong reported a race between __unix_gc() and\nqueue_oob().\n\n__unix_gc() tries to garbage-collect close()d inflight sockets,\nand then if the socket has MSG_OOB in unix_sk(sk)->oob_skb, GC\nwill drop the reference and set NULL to it locklessly.\n\nHowever, the peer socket still can send MSG_OOB message and\nqueue_oob() can update unix_sk(sk)->oob_skb concurrently, leading\nNULL pointer dereference. [0]\n\nTo fix the issue, let's update unix_sk(sk)->oob_skb under the\nsk_receive_queue's lock and take it everywhere we touch oob_skb.\n\nNote that we defer kfree_skb() in manage_oob() to silence lockdep\nfalse-positive (See [1]).\n\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n PF: supervisor write access in kernel mode\n PF: error_code(0x0002) - not-present page\nPGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0\nOops: 0002 [#1] PREEMPT SMP PTI\nCPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events delayed_fput\nRIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847)\nCode: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc\nRSP: 0018:ffffc900001bfd48 EFLAGS: 00000002\nRAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9\nRDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00\nRBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001\nR10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00\nR13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80\nFS: 0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n <TASK>\n unix_release_sock (net/unix/af_unix.c:654)\n unix_release (net/unix/af_unix.c:1050)\n __sock_release (net/socket.c:660)\n sock_close (net/socket.c:1423)\n __fput (fs/file_table.c:423)\n delayed_fput (fs/file_table.c:444 (discriminator 3))\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416)\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:257)\n </TASK>\nModules linked in:\nCR2: 0000000000000008

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: Use request_module_nowait\n\nThis appears to work around a deadlock regression that came in\nwith the LED merge in 6.9.\n\nThe deadlock happens on my system with 24 iwlwifi radios, so maybe\nit something like all worker threads are busy and some work that needs\nto complete cannot complete.\n\n[also remove unnecessary "load_module" var and now-wrong comment]

In the Linux kernel, the following vulnerability has been resolved:\n\nKEYS: trusted: Fix memory leak in tpm2_key_encode()\n\n'scratch' is never freed. Fix this by calling kfree() in the success, and\nin the error case.

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/9p: only translate RWX permissions for plain 9P2000\n\nGarbage in plain 9P2000's perm bits is allowed through, which causes it\nto be able to set (among others) the suid bit. This was presumably not\nthe intent since the unix extended bits are handled explicitly and\nconditionally on .u.

In the Linux kernel, the following vulnerability has been resolved:\n\ntracefs: Reset permissions on remount if permissions are options\n\nThere's an inconsistency with the way permissions are handled in tracefs.\nBecause the permissions are generated when accessed, they default to the\nroot inode's permission if they were never set by the user. If the user\nsets the permissions, then a flag is set and the permissions are saved via\nthe inode (for tracefs files) or an internal attribute field (for\neventfs).\n\nBut if a remount happens that specify the permissions, all the files that\nwere not changed by the user gets updated, but the ones that were are not.\nIf the user were to remount the file system with a given permission, then\nall files and directories within that file system should be updated.\n\nThis can cause security issues if a file's permission was updated but the\nadmin forgot about it. They could incorrectly think that remounting with\npermissions set would update all files, but miss some.\n\nFor example:\n\n # cd /sys/kernel/tracing\n # chgrp 1002 current_tracer\n # ls -l\n[..]\n -rw-r----- 1 root root 0 May 1 21:25 buffer_size_kb\n -rw-r----- 1 root root 0 May 1 21:25 buffer_subbuf_size_kb\n -r--r----- 1 root root 0 May 1 21:25 buffer_total_size_kb\n -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer\n -rw-r----- 1 root root 0 May 1 21:25 dynamic_events\n -r--r----- 1 root root 0 May 1 21:25 dyn_ftrace_total_info\n -r--r----- 1 root root 0 May 1 21:25 enabled_functions\n\nWhere current_tracer now has group "lkp".\n\n # mount -o remount,gid=1001 .\n # ls -l\n -rw-r----- 1 root tracing 0 May 1 21:25 buffer_size_kb\n -rw-r----- 1 root tracing 0 May 1 21:25 buffer_subbuf_size_kb\n -r--r----- 1 root tracing 0 May 1 21:25 buffer_total_size_kb\n -rw-r----- 1 root lkp 0 May 1 21:25 current_tracer\n -rw-r----- 1 root tracing 0 May 1 21:25 dynamic_events\n -r--r----- 1 root tracing 0 May 1 21:25 dyn_ftrace_total_info\n -r--r----- 1 root tracing 0 May 1 21:25 enabled_functions\n\nEverything changed but the "current_tracer".\n\nAdd a new link list that keeps track of all the tracefs_inodes which has\nthe permission flags that tell if the file/dir should use the root inode's\npermission or not. Then on remount, clear all the flags so that the\ndefault behavior of using the root inode's permission is done for all\nfiles and directories.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ks8851: Queue RX packets in IRQ handler instead of disabling BHs\n\nCurrently the driver uses local_bh_disable()/local_bh_enable() in its\nIRQ handler to avoid triggering net_rx_action() softirq on exit from\nnetif_rx(). The net_rx_action() could trigger this driver .start_xmit\ncallback, which is protected by the same lock as the IRQ handler, so\ncalling the .start_xmit from netif_rx() from the IRQ handler critical\nsection protected by the lock could lead to an attempt to claim the\nalready claimed lock, and a hang.\n\nThe local_bh_disable()/local_bh_enable() approach works only in case\nthe IRQ handler is protected by a spinlock, but does not work if the\nIRQ handler is protected by mutex, i.e. this works for KS8851 with\nParallel bus interface, but not for KS8851 with SPI bus interface.\n\nRemove the BH manipulation and instead of calling netif_rx() inside\nthe IRQ handler code protected by the lock, queue all the received\nSKBs in the IRQ handler into a queue first, and once the IRQ handler\nexits the critical section protected by the lock, dequeue all the\nqueued SKBs and push them all into netif_rx(). At this point, it is\nsafe to trigger the net_rx_action() softirq, since the netif_rx()\ncall is outside of the lock that protects the IRQ handler.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/debugfs: Fix two locking issues with thermal zone debug\n\nWith the current thermal zone locking arrangement in the debugfs code,\nuser space can open the "mitigations" file for a thermal zone before\nthe zone's debugfs pointer is set which will result in a NULL pointer\ndereference in tze_seq_start().\n\nMoreover, thermal_debug_tz_remove() is not called under the thermal\nzone lock, so it can run in parallel with the other functions accessing\nthe thermal zone's struct thermal_debugfs object. Then, it may clear\ntz->debugfs after one of those functions has checked it and the\nstruct thermal_debugfs object may be freed prematurely.\n\nTo address the first problem, pass a pointer to the thermal zone's\nstruct thermal_debugfs object to debugfs_create_file() in\nthermal_debug_tz_add() and make tze_seq_start(), tze_seq_next(),\ntze_seq_stop(), and tze_seq_show() retrieve it from s->private\ninstead of a pointer to the thermal zone object. This will ensure\nthat tz_debugfs will be valid across the "mitigations" file accesses\nuntil thermal_debugfs_remove_id() called by thermal_debug_tz_remove()\nremoves that file.\n\nTo address the second problem, use tz->lock in thermal_debug_tz_remove()\naround the tz->debugfs value check (in case the same thermal zone is\nremoved at the same time in two different threads) and its reset to NULL.\n\nCc :6.8+ <stable@vger.kernel.org> # 6.8+

In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()\n\nIf we fail to allocate propname buffer, we need to drop the reference\ncount we just took. Because the pinctrl_dt_free_maps() includes the\ndroping operation, here we call it directly.

In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Fix nfsd4_encode_fattr4() crasher\n\nEnsure that args.acl is initialized early. It is used in an\nunconditional call to kfree() on the way out of\nnfsd4_encode_fattr4().

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/debugfs: Free all thermal zone debug memory on zone removal\n\nBecause thermal_debug_tz_remove() does not free all memory allocated for\nthermal zone diagnostics, some of that memory becomes unreachable after\nfreeing the thermal zone's struct thermal_debugfs object.\n\nAddress this by making thermal_debug_tz_remove() free all of the memory\nin question.\n\nCc :6.8+ <stable@vger.kernel.org> # 6.8+

In the Linux kernel, the following vulnerability has been resolved:\n\nqibfs: fix dentry leak\n\nsimple_recursive_removal() drops the pinning references to all positives\nin subtree. For the cases when its argument has been kept alive by\nthe pinning alone that's exactly the right thing to do, but here\nthe argument comes from dcache lookup, that needs to be balanced by\nexplicit dput().\n\nFucked-up-by: Al Viro <viro@zeniv.linux.org.uk>

In the Linux kernel, the following vulnerability has been resolved:\n\nphonet: fix rtm_phonet_notify() skb allocation\n\nfill_route() stores three components in the skb:\n\n- struct rtmsg\n- RTA_DST (u8)\n- RTA_OIF (u32)\n\nTherefore, rtm_phonet_notify() should use\n\nNLMSG_ALIGN(sizeof(struct rtmsg)) +\nnla_total_size(1) +\nnla_total_size(4)

In the Linux kernel, the following vulnerability has been resolved:\n\nReapply "drm/qxl: simplify qxl_fence_wait"\n\nThis reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.\n\nStephen Rostedt reports:\n "I went to run my tests on my VMs and the tests hung on boot up.\n Unfortunately, the most I ever got out was:\n\n [ 93.607888] Testing event system initcall: OK\n [ 93.667730] Running tests on all trace events:\n [ 93.669757] Testing all events: OK\n [ 95.631064] ------------[ cut here ]------------\n Timed out after 60 seconds"\n\nand further debugging points to a possible circular locking dependency\nbetween the console_owner locking and the worker pool locking.\n\nReverting the commit allows Steve's VM to boot to completion again.\n\n[ This may obviously result in the "[TTM] Buffer eviction failed"\n messages again, which was the reason for that original revert. But at\n this point this seems preferable to a non-booting system... ]

In the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan\n\nmake_uffd_wp_pte() was previously doing:\n\n pte = ptep_get(ptep);\n ptep_modify_prot_start(ptep);\n pte = pte_mkuffd_wp(pte);\n ptep_modify_prot_commit(ptep, pte);\n\nBut if another thread accessed or dirtied the pte between the first 2\ncalls, this could lead to loss of that information. Since\nptep_modify_prot_start() gets and clears atomically, the following is the\ncorrect pattern and prevents any possible race. Any access after the\nfirst call would see an invalid pte and cause a fault:\n\n pte = ptep_modify_prot_start(ptep);\n pte = pte_mkuffd_wp(pte);\n ptep_modify_prot_commit(ptep, pte);

In the Linux kernel, the following vulnerability has been resolved:\n\nxdp: use flags field to disambiguate broadcast redirect\n\nWhen redirecting a packet using XDP, the bpf_redirect_map() helper will set\nup the redirect destination information in struct bpf_redirect_info (using\nthe __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect()\nfunction will read this information after the XDP program returns and pass\nthe frame on to the right redirect destination.\n\nWhen using the BPF_F_BROADCAST flag to do multicast redirect to a whole\nmap, __bpf_xdp_redirect_map() sets the 'map' pointer in struct\nbpf_redirect_info to point to the destination map to be broadcast. And\nxdp_do_redirect() reacts to the value of this map pointer to decide whether\nit's dealing with a broadcast or a single-value redirect. However, if the\ndestination map is being destroyed before xdp_do_redirect() is called, the\nmap pointer will be cleared out (by bpf_clear_redirect_map()) without\nwaiting for any XDP programs to stop running. This causes xdp_do_redirect()\nto think that the redirect was to a single target, but the target pointer\nis also NULL (since broadcast redirects don't have a single target), so\nthis causes a crash when a NULL pointer is passed to dev_map_enqueue().\n\nTo fix this, change xdp_do_redirect() to react directly to the presence of\nthe BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info\nto disambiguate between a single-target and a broadcast redirect. And only\nread the 'map' pointer if the broadcast flag is set, aborting if that has\nbeen cleared out in the meantime. This prevents the crash, while keeping\nthe atomic (cmpxchg-based) clearing of the map pointer itself, and without\nadding any more checks in the non-broadcast fast path.

In the Linux kernel, the following vulnerability has been resolved:\n\nice: ensure the copied buf is NUL terminated\n\nCurrently, we allocate a count-sized kernel buffer and copy count bytes\nfrom userspace to that buffer. Later, we use sscanf on this buffer but we\ndon't ensure that the string is terminated inside the buffer, this can lead\nto OOB read when using sscanf. Fix this issue by using memdup_user_nul\ninstead of memdup_user.

In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/debugfs: Prevent use-after-free from occurring after cdev removal\n\nSince thermal_debug_cdev_remove() does not run under cdev->lock, it can\nrun in parallel with thermal_debug_cdev_state_update() and it may free\nthe struct thermal_debugfs object used by the latter after it has been\nchecked against NULL.\n\nIf that happens, thermal_debug_cdev_state_update() will access memory\nthat has been freed already causing the kernel to crash.\n\nAddress this by using cdev->lock in thermal_debug_cdev_remove() around\nthe cdev->debugfs value check (in case the same cdev is removed at the\nsame time in two different threads) and its reset to NULL.\n\nCc :6.8+ <stable@vger.kernel.org> # 6.8+

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/cio: Ensure the copied buf is NUL terminated\n\nCurrently, we allocate a lbuf-sized kernel buffer and copy lbuf from\nuserspace to that buffer. Later, we use scanf on this buffer but we don't\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using scanf. Fix this issue by using memdup_user_nul instead.

In the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix null pointer dereference within spi_sync\n\nIf spi_sync() is called with the non-empty queue and the same spi_message\nis then reused, the complete callback for the message remains set while\nthe context is cleared, leading to a null pointer dereference when the\ncallback is invoked from spi_finalize_current_message().\n\nWith function inlining disabled, the call stack might look like this:\n\n _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58\n complete_with_flags from spi_complete+0x8/0xc\n spi_complete from spi_finalize_current_message+0xec/0x184\n spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474\n spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230\n __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4\n __spi_transfer_message_noqueue from __spi_sync+0x204/0x248\n __spi_sync from spi_sync+0x24/0x3c\n spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd]\n mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154\n _regmap_raw_read from _regmap_bus_read+0x44/0x70\n _regmap_bus_read from _regmap_read+0x60/0xd8\n _regmap_read from regmap_read+0x3c/0x5c\n regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd]\n mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd]\n mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78\n irq_thread_fn from irq_thread+0x118/0x1f4\n irq_thread from kthread+0xd8/0xf4\n kthread from ret_from_fork+0x14/0x28\n\nFix this by also setting message->complete to NULL when the transfer is\ncomplete.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when devlink reload during initialization\n\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash.\n\nThis patch fixes this by registering the devlink after\nhardware initialization.

In the Linux kernel, the following vulnerability has been resolved:\n\ngpiolib: cdev: fix uninitialised kfifo\n\nIf a line is requested with debounce, and that results in debouncing\nin software, and the line is subsequently reconfigured to enable edge\ndetection then the allocation of the kfifo to contain edge events is\noverlooked. This results in events being written to and read from an\nuninitialised kfifo. Read events are returned to userspace.\n\nInitialise the kfifo in the case where the software debounce is\nalready active.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: uvc: use correct buffer size when parsing configfs lists\n\nThis commit fixes uvc gadget support on 32-bit platforms.\n\nCommit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for\nreuse") introduced a helper function __uvcg_iter_item_entries() to aid\nwith parsing lists of items on configfs attributes stores. This function\nis a generalization of another very similar function, which used a\nstack-allocated temporary buffer of fixed size for each item in the list\nand used the sizeof() operator to check for potential buffer overruns.\nThe new function was changed to allocate the now variably sized temp\nbuffer on heap, but wasn't properly updated to also check for max buffer\nsize using the computed size instead of sizeof() operator.\n\nAs a result, the maximum item size was 7 (plus null terminator) on\n64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just\nbarely enough, 3 is definitely too small for some of UVC configfs\nattributes. For example, dwFrameInteval, specified in 100ns units,\nusually has 6-digit item values, e.g. 166666 for 60fps.

In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: Check for port partner validity before consuming it\n\ntypec_register_partner() does not guarantee partner registration\nto always succeed. In the event of failure, port->partner is set\nto the error value or NULL. Given that port->partner validity is\nnot checked, this results in the following crash:\n\nUnable to handle kernel NULL pointer dereference at virtual address xx\n pc : run_state_machine+0x1bc8/0x1c08\n lr : run_state_machine+0x1b90/0x1c08\n..\n Call trace:\n run_state_machine+0x1bc8/0x1c08\n tcpm_state_machine_work+0x94/0xe4\n kthread_worker_fn+0x118/0x328\n kthread+0x1d0/0x23c\n ret_from_fork+0x10/0x20\n\nTo prevent the crash, check for port->partner validity before\nderefencing it in all the call sites.

In the Linux kernel, the following vulnerability has been resolved:\n\nmaple_tree: fix mas_empty_area_rev() null pointer dereference\n\nCurrently the code calls mas_start() followed by mas_data_end() if the\nmaple state is MA_START, but mas_start() may return with the maple state\nnode == NULL. This will lead to a null pointer dereference when checking\ninformation in the NULL node, which is done in mas_data_end().\n\nAvoid setting the offset if there is no node by waiting until after the\nmaple state is checked for an empty or single entry state.\n\nA user could trigger the events to cause a kernel oops by unmapping all\nvmas to produce an empty maple tree, then mapping a vma that would cause\nthe scenario described above.

In the Linux kernel, the following vulnerability has been resolved:\n\nworkqueue: Fix selection of wake_cpu in kick_pool()\n\nWith cpu_possible_mask=0-63 and cpu_online_mask=0-7 the following\nkernel oops was observed:\n\nsmp: Bringing up secondary CPUs ...\nsmp: Brought up 1 node, 8 CPUs\nUnable to handle kernel pointer dereference in virtual kernel address space\nFailing address: 0000000000000000 TEID: 0000000000000803\n[..]\n Call Trace:\narch_vcpu_is_preempted+0x12/0x80\nselect_idle_sibling+0x42/0x560\nselect_task_rq_fair+0x29a/0x3b0\ntry_to_wake_up+0x38e/0x6e0\nkick_pool+0xa4/0x198\n__queue_work.part.0+0x2bc/0x3a8\ncall_timer_fn+0x36/0x160\n__run_timers+0x1e2/0x328\n__run_timer_base+0x5a/0x88\nrun_timer_softirq+0x40/0x78\n__do_softirq+0x118/0x388\nirq_exit_rcu+0xc0/0xd8\ndo_ext_irq+0xae/0x168\next_int_handler+0xbe/0xf0\npsw_idle_exit+0x0/0xc\ndefault_idle_call+0x3c/0x110\ndo_idle+0xd4/0x158\ncpu_startup_entry+0x40/0x48\nrest_init+0xc6/0xc8\nstart_kernel+0x3c4/0x5e0\nstartup_continue+0x3c/0x50\n\nThe crash is caused by calling arch_vcpu_is_preempted() for an offline\nCPU. To avoid this, select the cpu with cpumask_any_and_distribute()\nto mask __pod_cpumask with cpu_online_mask. In case no cpu is left in\nthe pool, skip the assignment.\n\ntj: This doesn't fully fix the bug as CPUs can still go down between picking\nthe target CPU and the wake call. Fixing that likely requires adding\ncpu_online() test to either the sched or s390 arch code. However, regardless\nof how that is fixed, workqueue shouldn't be picking a CPU which isn't\nonline as that would result in unpredictable and worse behavior.

In the Linux kernel, the following vulnerability has been resolved:\n\ne1000e: change usleep_range to udelay in PHY mdic access\n\nThis is a partial revert of commit 6dbdd4de0362 ("e1000e: Workaround\nfor sporadic MDI error on Meteor Lake systems"). The referenced commit\nused usleep_range inside the PHY access routines, which are sometimes\ncalled from an atomic context. This can lead to a kernel panic in some\nscenarios, such as cable disconnection and reconnection on vPro systems.\n\nSolve this by changing the usleep_range calls back to udelay.

In the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()\n\nThis was missed because of the function pointer indirection.\n\nnvidia_smmu_context_fault() is also installed as a irq function, and the\n'void *' was changed to a struct arm_smmu_domain. Since the iommu_domain\nis embedded at a non-zero offset this causes nvidia_smmu_context_fault()\nto miscompute the offset. Fixup the types.\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120\n Mem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000\n [0000000000000120] pgd=0000000000000000, p4d=0000000000000000\n Internal error: Oops: 0000000096000004 [#1] SMP\n Modules linked in:\n CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1\n Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023\n Workqueue: events_unbound deferred_probe_work_func\n pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : nvidia_smmu_context_fault+0x1c/0x158\n lr : __free_irq+0x1d4/0x2e8\n sp : ffff80008044b6f0\n x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970\n x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30\n x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000\n x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff\n x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888\n x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0\n x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c\n x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f\n x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000\n x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057\n Call trace:\n nvidia_smmu_context_fault+0x1c/0x158\n __free_irq+0x1d4/0x2e8\n free_irq+0x3c/0x80\n devm_free_irq+0x64/0xa8\n arm_smmu_domain_free+0xc4/0x158\n iommu_domain_free+0x44/0xa0\n iommu_deinit_device+0xd0/0xf8\n __iommu_group_remove_device+0xcc/0xe0\n iommu_bus_notifier+0x64/0xa8\n notifier_call_chain+0x78/0x148\n blocking_notifier_call_chain+0x4c/0x90\n bus_notify+0x44/0x70\n device_del+0x264/0x3e8\n pci_remove_bus_device+0x84/0x120\n pci_remove_root_bus+0x5c/0xc0\n dw_pcie_host_deinit+0x38/0xe0\n tegra_pcie_config_rp+0xc0/0x1f0\n tegra_pcie_dw_probe+0x34c/0x700\n platform_probe+0x70/0xe8\n really_probe+0xc8/0x3a0\n __driver_probe_device+0x84/0x160\n driver_probe_device+0x44/0x130\n __device_attach_driver+0xc4/0x170\n bus_for_each_drv+0x90/0x100\n __device_attach+0xa8/0x1c8\n device_initial_probe+0x1c/0x30\n bus_probe_device+0xb0/0xc0\n deferred_probe_work_func+0xbc/0x120\n process_one_work+0x194/0x490\n worker_thread+0x284/0x3b0\n kthread+0xf4/0x108\n ret_from_fork+0x10/0x20\n Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1)

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: use memalloc_nofs_save() in page_cache_ra_order()\n\nSee commit f2c817bed58d ("mm: use memalloc_nofs_save in readahead path"),\nensure that page_cache_ra_order() do not attempt to reclaim file-backed\npages too, or it leads to a deadlock, found issue when test ext4 large\nfolio.\n\n INFO: task DataXceiver for:7494 blocked for more than 120 seconds.\n "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200\n Call trace:\n __switch_to+0x14c/0x240\n __schedule+0x82c/0xdd0\n schedule+0x58/0xf0\n io_schedule+0x24/0xa0\n __folio_lock+0x130/0x300\n migrate_pages_batch+0x378/0x918\n migrate_pages+0x350/0x700\n compact_zone+0x63c/0xb38\n compact_zone_order+0xc0/0x118\n try_to_compact_pages+0xb0/0x280\n __alloc_pages_direct_compact+0x98/0x248\n __alloc_pages+0x510/0x1110\n alloc_pages+0x9c/0x130\n folio_alloc+0x20/0x78\n filemap_alloc_folio+0x8c/0x1b0\n page_cache_ra_order+0x174/0x308\n ondemand_readahead+0x1c8/0x2b8\n page_cache_async_ra+0x68/0xb8\n filemap_readahead.isra.0+0x64/0xa8\n filemap_get_pages+0x3fc/0x5b0\n filemap_splice_read+0xf4/0x280\n ext4_file_splice_read+0x2c/0x48 [ext4]\n vfs_splice_read.part.0+0xa8/0x118\n splice_direct_to_actor+0xbc/0x288\n do_splice_direct+0x9c/0x108\n do_sendfile+0x328/0x468\n __arm64_sys_sendfile64+0x8c/0x148\n invoke_syscall+0x4c/0x118\n el0_svc_common.constprop.0+0xc8/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x4c/0x1f8\n el0t_64_sync_handler+0xc0/0xc8\n el0t_64_sync+0x188/0x190

In the Linux kernel, the following vulnerability has been resolved:\n\nmm/userfaultfd: reset ptes when close() for wr-protected ones\n\nUserfaultfd unregister includes a step to remove wr-protect bits from all\nthe relevant pgtable entries, but that only covered an explicit\nUFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover\nthat too. This fixes a WARN trace.\n\nThe only user visible side effect is the user can observe leftover\nwr-protect bits even if the user close()ed on an userfaultfd when\nreleasing the last reference of it. However hopefully that should be\nharmless, and nothing bad should happen even if so.\n\nThis change is now more important after the recent page-table-check\npatch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check:\nsupport userfault wr-protect entries")), as we'll do sanity check on\nuffd-wp bits without vma context. So it's better if we can 100%\nguarantee no uffd-wp bit leftovers, to make sure each report will be\nvalid.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: fix info leak when fetching board id\n\nAdd the missing sanity check when fetching the board id to avoid leaking\nslab data when later requesting the firmware.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: fix info leak when fetching fw build id\n\nAdd the missing sanity checks and move the 255-byte build-id buffer off\nthe stack to avoid leaking stack data through debugfs in case the\nbuild-info reply is malformed.

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-af: fix the double free in rvu_npc_freemem()\n\nClang static checker(scan-build) warning：\ndrivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:line 2184, column 2\nAttempt to free released memory.\n\nnpc_mcam_rsrcs_deinit() has released 'mcam->counters.bmap'. Deleted this\nredundant kfree() to fix this double free problem.

In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer\n\nBtrfs clears the content of an extent buffer marked as\nEXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is\nintroduced to prevent a write hole of an extent buffer, which is once\nallocated, marked dirty, but turns out unnecessary and cleaned up within\none transaction operation.\n\nCurrently, btrfs_clear_buffer_dirty() marks the extent buffer as\nEXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call\nhappens while the buffer is under IO (with the WRITEBACK flag set,\nwithout the DIRTY flag), we can add the ZEROOUT flag and clear the\nbuffer's content just before a bio submission. As a result:\n\n1) it can lead to adding faulty delayed reference item which leads to a\n FS corrupted (EUCLEAN) error, and\n\n2) it writes out cleared tree node on disk\n\nThe former issue is previously discussed in [1]. The corruption happens\nwhen it runs a delayed reference update. So, on-disk data is safe.\n\n[1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/\n\nThe latter one can reach on-disk data. But, as that node is already\nprocessed by btrfs_clear_buffer_dirty(), that will be invalidated in the\nnext transaction commit anyway. So, the chance of hitting the corruption\nis relatively small.\n\nAnyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to\nkeep the content under IO intact.

In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11\n\nWhile doing multiple S4 stress tests, GC/RLC/PMFW get into\nan invalid state resulting into hard hangs.\n\nAdding a GFX reset as workaround just before sending the\nMP1_UNLOAD message avoids this failure.

In the Linux kernel, the following vulnerability has been resolved:\n\nJulia Lawall reported this null pointer dereference, this should fix it.

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when devlink reload during pf initialization\n\nThe devlink reload process will access the hardware resources,\nbut the register operation is done before the hardware is initialized.\nSo, processing the devlink reload during initialization may lead to kernel\ncrash. This patch fixes this by taking devl_lock during initialization.

In the Linux kernel, the following vulnerability has been resolved:\n\nnouveau/uvmm: fix addr/range calcs for remap operations\n\ndEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8\nwas causing a remap operation like the below.\n\nop_remap: prev: 0000003fffed0000 00000000000f0000 00000000a5abd18a 0000000000000000\nop_remap: next:\nop_remap: unmap: 0000003fffed0000 0000000000100000 0\nop_map: map: 0000003ffffc0000 0000000000010000 000000005b1ba33c 00000000000e0000\n\nThis was resulting in an unmap operation from 0x3fffed0000+0xf0000, 0x100000\nwhich was corrupting the pagetables and oopsing the kernel.\n\nFixes the prev + unmap range calcs to use start/end and map back to addr/range.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: check for NULL idev in ip_route_use_hint()\n\nsyzbot was able to trigger a NULL deref in fib_validate_source()\nin an old tree [1].\n\nIt appears the bug exists in latest trees.\n\nAll calls to __in_dev_get_rcu() must be checked for a NULL result.\n\n[1]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425\nCode: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf\nRSP: 0018:ffffc900015fee40 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0\nRDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0\nRBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000\nR10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000\nFS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231\n ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327\n ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]\n ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638\n ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673\n __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]\n __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620\n __netif_receive_skb_list net/core/dev.c:5672 [inline]\n netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764\n netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816\n xdp_recv_frames net/bpf/test_run.c:257 [inline]\n xdp_test_run_batch net/bpf/test_run.c:335 [inline]\n bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363\n bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376\n bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736\n __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115\n __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]\n __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199

In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: fix dpll_pin_on_pin_register() for multiple parent pins\n\nIn scenario where pin is registered with multiple parent pins via\ndpll_pin_on_pin_register(..), all belonging to the same dpll device.\nA second call to dpll_pin_on_pin_unregister(..) would cause a call trace,\nas it tries to use already released registration resources (due to fix\nintroduced in b446631f355e). In this scenario pin was registered twice,\nso resources are not yet expected to be release until each registered\npin/pin pair is unregistered.\n\nCurrently, the following crash/call trace is produced when ice driver is\nremoved on the system with installed E810T NIC which includes dpll device:\n\nWARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30\nRIP: 0010:dpll_pin_ops+0x20/0x30\nCall Trace:\n ? __warn+0x7f/0x130\n ? dpll_pin_ops+0x20/0x30\n dpll_msg_add_pin_freq+0x37/0x1d0\n dpll_cmd_pin_get_one+0x1c0/0x400\n ? __nlmsg_put+0x63/0x80\n dpll_pin_event_send+0x93/0x140\n dpll_pin_on_pin_unregister+0x3f/0x100\n ice_dpll_deinit_pins+0xa1/0x230 [ice]\n ice_remove+0xf1/0x210 [ice]\n\nFix by adding a parent pointer as a cookie when creating a registration,\nalso when searching for it. For the regular pins pass NULL, this allows to\ncreate separated registration for each parent the pin is registered with.

In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix the pre-flush when appending to a file in writethrough mode\n\nIn netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH\nor O_*SYNC or RWF_*SYNC was specified, write-through caching is performed\non a buffered file. When setting up for write-through, we flush any\nconflicting writes in the region and wait for the write to complete,\nfailing if there's a write error to return.\n\nThe issue arises if we're writing at or above the EOF position because we\nskip the flush and - more importantly - the wait. This becomes a problem\nif there's a partial folio at the end of the file that is being written out\nand we want to make a write to it too. Both the already-running write and\nthe write we start both want to clear the writeback mark, but whoever is\nsecond causes a warning looking something like:\n\n ------------[ cut here ]------------\n R=00000012: folio 11 is not under writeback\n WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105\n ...\n CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ...\n ...\n Workqueue: events_unbound netfs_write_collection_worker\n ...\n RIP: 0010:netfs_writeback_lookup_folio\n\nFix this by making the flush-and-wait unconditional. It will do nothing if\nthere are no folios in the pagecache and will return quickly if there are\nno folios in the region specified.\n\nFurther, move the WBC attachment above the flush call as the flush is going\nto attach a WBC and detach it again if it is not present - and since we\nneed one anyway we might as well share it.

In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: qcom: uefisecapp: Fix memory related IO errors and crashes\n\nIt turns out that while the QSEECOM APP_SEND command has specific fields\nfor request and response buffers, uefisecapp expects them both to be in\na single memory region. Failure to adhere to this has (so far) resulted\nin either no response being written to the response buffer (causing an\nEIO to be emitted down the line), the SCM call to fail with EINVAL\n(i.e., directly from TZ/firmware), or the device to be hard-reset.\n\nWhile this issue can be triggered deterministically, in the current form\nit seems to happen rather sporadically (which is why it has gone\nunnoticed during earlier testing). This is likely due to the two\nkzalloc() calls (for request and response) being directly after each\nother. Which means that those likely return consecutive regions most of\nthe time, especially when not much else is going on in the system.\n\nFix this by allocating a single memory region for both request and\nresponse buffers, properly aligning both structs inside it. This\nunfortunately also means that the qcom_scm_qseecom_app_send() interface\nneeds to be restructured, as it should no longer map the DMA regions\nseparately. Therefore, move the responsibility of DMA allocation (or\nmapping) to the caller.

In the Linux kernel, the following vulnerability has been resolved:\n\nmm: turn folio_test_hugetlb into a PageType\n\nThe current folio_test_hugetlb() can be fooled by a concurrent folio split\ninto returning true for a folio which has never belonged to hugetlbfs. \nThis can't happen if the caller holds a refcount on it, but we have a few\nplaces (memory-failure, compaction, procfs) which do not and should not\ntake a speculative reference.\n\nSince hugetlb pages do not use individual page mapcounts (they are always\nfully mapped and use the entire_mapcount field to record the number of\nmappings), the PageType field is available now that page_mapcount()\nignores the value in this field.\n\nIn compaction and with CONFIG_DEBUG_VM enabled, the current implementation\ncan result in an oops, as reported by Luis. This happens since 9c5ccf2db04b\n("mm: remove HUGETLB_PAGE_DTOR") effectively added some VM_BUG_ON() checks\nin the PageHuge() testing path.\n\n[willy@infradead.org: update vmcoreinfo]\n Link: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: marvell: a3700-comphy: Fix out of bounds read\n\nThere is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr'\nevery iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'.\n\nMake sure 'gbe_phy_init[addr]' is used when all elements of\n'gbe_phy_init_fix' array are handled.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix loading 64-bit NOMMU kernels past the start of RAM\n\ncommit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear\nmapping") added logic to allow using RAM below the kernel load address.\nHowever, this does not work for NOMMU, where PAGE_OFFSET is fixed to the\nkernel load address. Since that range of memory corresponds to PFNs\nbelow ARCH_PFN_OFFSET, mm initialization runs off the beginning of\nmem_map and corrupts adjacent kernel memory. Fix this by restoring the\nprevious behavior for NOMMU kernels.

In the Linux kernel, the following vulnerability has been resolved:\n\nphy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered\n\nThe power_supply frame-work is not really designed for there to be\nlong living in kernel references to power_supply devices.\n\nSpecifically unregistering a power_supply while some other code has\na reference to it triggers a WARN in power_supply_unregister():\n\n WARN_ON(atomic_dec_return(&psy->use_cnt));\n\nFolllowed by the power_supply still getting removed and the\nbacking data freed anyway, leaving the tusb1210 charger-detect code\nwith a dangling reference, resulting in a crash the next time\ntusb1210_get_online() is called.\n\nFix this by only holding the reference in tusb1210_get_online()\nfreeing it at the end of the function. Note this still leaves\na theoretical race window, but it avoids the issue when manually\nrmmod-ing the charger chip driver during development.

In the Linux kernel, the following vulnerability has been resolved:\n\nbounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS\n\nbits_per() rounds up to the next power of two when passed a power of\ntwo. This causes crashes on some machines and configurations.

In the Linux kernel, the following vulnerability has been resolved:\n\nocteontx2-pf: Fix transmit scheduler resource leak\n\nInorder to support shaping and scheduling, Upon class creation\nNetdev driver allocates trasmit schedulers.\n\nThe previous patch which added support for Round robin scheduling has\na bug due to which driver is not freeing transmit schedulers post\nclass deletion.\n\nThis patch fixes the same.

In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix q->blkg_list corruption during disk rebind\n\nMultiple gendisk instances can allocated/added for single request queue\nin case of disk rebind. blkg may still stay in q->blkg_list when calling\nblkcg_init_disk() for rebind, then q->blkg_list becomes corrupted.\n\nFix the list corruption issue by:\n\n- add blkg_init_queue() to initialize q->blkg_list & q->blkcg_mutex only\n- move calling blkg_init_queue() into blk_alloc_queue()\n\nThe list corruption should be started since commit f1c006f1c685 ("blk-cgroup:\nsynchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()")\nwhich delays removing blkg from q->blkg_list into blkg_free_workfn().

In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Clear stale u->oob_skb.\n\nsyzkaller started to report deadlock of unix_gc_lock after commit\n4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but\nit just uncovers the bug that has been there since commit 314001f0bf92\n("af_unix: Add OOB support").\n\nThe repro basically does the following.\n\n from socket import *\n from array import array\n\n c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)\n c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB)\n c2.recv(1) # blocked as no normal data in recv queue\n\n c2.close() # done async and unblock recv()\n c1.close() # done async and trigger GC\n\nA socket sends its file descriptor to itself as OOB data and tries to\nreceive normal data, but finally recv() fails due to async close().\n\nThe problem here is wrong handling of OOB skb in manage_oob(). When\nrecvmsg() is called without MSG_OOB, manage_oob() is called to check\nif the peeked skb is OOB skb. In such a case, manage_oob() pops it\nout of the receive queue but does not clear unix_sock(sk)->oob_skb.\nThis is wrong in terms of uAPI.\n\nLet's say we send "hello" with MSG_OOB, and "world" without MSG_OOB.\nThe 'o' is handled as OOB data. When recv() is called twice without\nMSG_OOB, the OOB data should be lost.\n\n >>> from socket import *\n >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)\n >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data\n 5\n >>> c1.send(b'world')\n 5\n >>> c2.recv(5) # OOB data is not received\n b'hell'\n >>> c2.recv(5) # OOB date is skipped\n b'world'\n >>> c2.recv(5, MSG_OOB) # This should return an error\n b'o'\n\nIn the same situation, TCP actually returns -EINVAL for the last\nrecv().\n\nAlso, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set\nEPOLLPRI even though the data has passed through by previous recv().\n\nTo avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing\nit from recv queue.\n\nThe reason why the old GC did not trigger the deadlock is because the\nold GC relied on the receive queue to detect the loop.\n\nWhen it is triggered, the socket with OOB data is marked as GC candidate\nbecause file refcount == inflight count (1). However, after traversing\nall inflight sockets, the socket still has a positive inflight count (1),\nthus the socket is excluded from candidates. Then, the old GC lose the\nchance to garbage-collect the socket.\n\nWith the old GC, the repro continues to create true garbage that will\nnever be freed nor detected by kmemleak as it's linked to the global\ninflight list. That's why we couldn't even notice the issue.

In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr\n\nAlthough ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it\nstill means hlist_for_each_entry_rcu can return an item that got removed\nfrom the list. The memory itself of such item is not freed thanks to RCU\nbut nothing guarantees the actual content of the memory is sane.\n\nIn particular, the reference count can be zero. This can happen if\nipv6_del_addr is called in parallel. ipv6_del_addr removes the entry\nfrom inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all\nreferences (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough\ntiming, this can happen:\n\n1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.\n\n2. Then, the whole ipv6_del_addr is executed for the given entry. The\n reference count drops to zero and kfree_rcu is scheduled.\n\n3. ipv6_get_ifaddr continues and tries to increments the reference count\n (in6_ifa_hold).\n\n4. The rcu is unlocked and the entry is freed.\n\n5. The freed entry is returned.\n\nPrevent increasing of the reference count in such case. The name\nin6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.\n\n[ 41.506330] refcount_t: addition on 0; use-after-free.\n[ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130\n[ 41.507413] Modules linked in: veth bridge stp llc\n[ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14\n[ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n[ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130\n[ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff\n[ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282\n[ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000\n[ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900\n[ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff\n[ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000\n[ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48\n[ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000\n[ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0\n[ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 41.516799] Call Trace:\n[ 41.517037] <TASK>\n[ 41.517249] ? __warn+0x7b/0x120\n[ 41.517535] ? refcount_warn_saturate+0xa5/0x130\n[ 41.517923] ? report_bug+0x164/0x190\n[ 41.518240] ? handle_bug+0x3d/0x70\n[ 41.518541] ? exc_invalid_op+0x17/0x70\n[ 41.520972] ? asm_exc_invalid_op+0x1a/0x20\n[ 41.521325] ? refcount_warn_saturate+0xa5/0x130\n[ 41.521708] ipv6_get_ifaddr+0xda/0xe0\n[ 41.522035] inet6_rtm_getaddr+0x342/0x3f0\n[ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10\n[ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0\n[ 41.523102] ? netlink_unicast+0x30f/0x390\n[ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[ 41.523832] netlink_rcv_skb+0x53/0x100\n[ 41.524157] netlink_unicast+0x23b/0x390\n[ 41.524484] netlink_sendmsg+0x1f2/0x440\n[ 41.524826] __sys_sendto+0x1d8/0x1f0\n[ 41.525145] __x64_sys_sendto+0x1f/0x30\n[ 41.525467] do_syscall_64+0xa5/0x1b0\n[ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a\n[ 41.526213] RIP: 0033:0x7fbc4cfcea9a\n[ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89\n[ 41.527942] RSP: 002b:00007ffcf54012a8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\n[ 41.528593] RAX: ffffffffffffffda RBX: 00007ffcf5401368 RCX: 00007fbc4cfcea9a\n[ 41.529173] RDX: 000000000000002c RSI: 00007fbc4b9d9bd0 RDI: 0000000000000005\n[ 41.529786] RBP: 00007fbc4bafb040 R08: 00007ffcf54013e0 R09: 000000000000000c\n[ 41.530375] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n[ 41.530977] R13: ffffffffc4653600 R14: 0000000000000001 R15: 00007fbc4ca85d1b\n[ 41.531573] </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\npds_core: Fix pdsc_check_pci_health function to use work thread\n\nWhen the driver notices fw_status == 0xff it tries to perform a PCI\nreset on itself via pci_reset_function() in the context of the driver's\nhealth thread. However, pdsc_reset_prepare calls\npdsc_stop_health_thread(), which attempts to stop/flush the health\nthread. This results in a deadlock because the stop/flush will never\ncomplete since the driver called pci_reset_function() from the health\nthread context. Fix by changing the pdsc_check_pci_health_function()\nto queue a newly introduced pdsc_pci_reset_thread() on the pdsc's\nwork queue.\n\nUnloading the driver in the fw_down/dead state uncovered another issue,\nwhich can be seen in the following trace:\n\nWARNING: CPU: 51 PID: 6914 at kernel/workqueue.c:1450 __queue_work+0x358/0x440\n[...]\nRIP: 0010:__queue_work+0x358/0x440\n[...]\nCall Trace:\n <TASK>\n ? __warn+0x85/0x140\n ? __queue_work+0x358/0x440\n ? report_bug+0xfc/0x1e0\n ? handle_bug+0x3f/0x70\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? __queue_work+0x358/0x440\n queue_work_on+0x28/0x30\n pdsc_devcmd_locked+0x96/0xe0 [pds_core]\n pdsc_devcmd_reset+0x71/0xb0 [pds_core]\n pdsc_teardown+0x51/0xe0 [pds_core]\n pdsc_remove+0x106/0x200 [pds_core]\n pci_device_remove+0x37/0xc0\n device_release_driver_internal+0xae/0x140\n driver_detach+0x48/0x90\n bus_remove_driver+0x6d/0xf0\n pci_unregister_driver+0x2e/0xa0\n pdsc_cleanup_module+0x10/0x780 [pds_core]\n __x64_sys_delete_module+0x142/0x2b0\n ? syscall_trace_enter.isra.18+0x126/0x1a0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7fbd9d03a14b\n[...]\n\nFix this by preventing the devcmd reset if the FW is not running.

In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: Fix not validating setsockopt user input\n\nsyzbot reported rfcomm_sock_setsockopt_old() is copying data without\nchecking user input length.\n\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset\ninclude/linux/sockptr.h:49 [inline]\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr\ninclude/linux/sockptr.h:55 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old\nnet/bluetooth/rfcomm/sock.c:632 [inline]\nBUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70\nnet/bluetooth/rfcomm/sock.c:673\nRead of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064

In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Register devlink first under devlink lock\n\nIn case device is having a non fatal FW error during probe, the\ndriver will report the error to user via devlink. This will trigger\na WARN_ON, since mlx5 is calling devlink_register() last.\nIn order to avoid the WARN_ON[1], change mlx5 to invoke devl_register()\nfirst under devlink lock.\n\n[1]\nWARNING: CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0\nCPU: 5 PID: 227 Comm: kworker/u16:3 Not tainted 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nWorkqueue: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core]\nRIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0\nCall Trace:\n <TASK>\n ? __warn+0x79/0x120\n ? devlink_recover_notify.constprop.0+0xb8/0xc0\n ? report_bug+0x17c/0x190\n ? handle_bug+0x3c/0x60\n ? exc_invalid_op+0x14/0x70\n ? asm_exc_invalid_op+0x16/0x20\n ? devlink_recover_notify.constprop.0+0xb8/0xc0\n devlink_health_report+0x4a/0x1c0\n mlx5_fw_reporter_err_work+0xa4/0xd0 [mlx5_core]\n process_one_work+0x1bb/0x3c0\n ? process_one_work+0x3c0/0x3c0\n worker_thread+0x4d/0x3c0\n ? process_one_work+0x3c0/0x3c0\n kthread+0xc6/0xf0\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n </TASK>

In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix oops when HEVC init fails\n\nThe stateless HEVC decoder saves the instance pointer in the context\nregardless if the initialization worked or not. This caused a use after\nfree, when the pointer is freed in case of a failure in the deinit\nfunction.\nOnly store the instance pointer when the initialization was successful,\nto solve this issue.\n\n Hardware name: Acer Tomato (rev3 - 4) board (DT)\n pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]\n lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]\n sp : ffff80008750bc20\n x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n x23: ffff80008750bc98 x22: 000000000000a003 x21: ffffd45c4cfae000\n x20: 0000000000000010 x19: ffff1299fd668310 x18: 000000000000001a\n x17: 000000040044ffff x16: ffffd45cb15dc648 x15: 0000000000000000\n x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80\n x11: 0000000000000001 x10: 0000000000001b30 x9 : ffffd45c4d12b488\n x8 : 1fffe25339380d81 x7 : 0000000000000001 x6 : ffff1299c9c06c00\n x5 : 0000000000000132 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 0000000000000010 x1 : ffff80008750bc98 x0 : 0000000000000000\n Call trace:\n vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]\n vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]\n vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec]\n vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec]\n vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec]\n mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec]\n fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec]\n v4l2_release+0x7c/0x100\n __fput+0x80/0x2d8\n __fput_sync+0x58/0x70\n __arm64_sys_close+0x40/0x90\n invoke_syscall+0x50/0x128\n el0_svc_common.constprop.0+0x48/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x38/0xd8\n el0t_64_sync_handler+0xc0/0xc8\n el0t_64_sync+0x1a8/0x1b0\n Code: d503201f f9401660 b900127f b900227f (f9400400)

In the Linux kernel, the following vulnerability has been resolved:\n\ns390/bpf: Fix bpf_plt pointer arithmetic\n\nKui-Feng Lee reported a crash on s390x triggered by the\ndummy_st_ops/dummy_init_ptr_arg test [1]:\n\n [<0000000000000002>] 0x2\n [<00000000009d5cde>] bpf_struct_ops_test_run+0x156/0x250\n [<000000000033145a>] __sys_bpf+0xa1a/0xd00\n [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50\n [<0000000000c4382c>] __do_syscall+0x244/0x300\n [<0000000000c59a40>] system_call+0x70/0x98\n\nThis is caused by GCC moving memcpy() after assignments in\nbpf_jit_plt(), resulting in NULL pointers being written instead of\nthe return and the target addresses.\n\nLooking at the GCC internals, the reordering is allowed because the\nalias analysis thinks that the memcpy() destination and the assignments'\nleft-hand-sides are based on different objects: new_plt and\nbpf_plt_ret/bpf_plt_target respectively, and therefore they cannot\nalias.\n\nThis is in turn due to a violation of the C standard:\n\n When two pointers are subtracted, both shall point to elements of the\n same array object, or one past the last element of the array object\n ...\n\n>From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects\nand cannot be subtracted. In the practical terms, doing so confuses the\nGCC's alias analysis.\n\nThe code was written this way in order to let the C side know a few\noffsets defined in the assembly. While nice, this is by no means\nnecessary. Fix the noncompliance by hardcoding these offsets.\n\n[1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: Fix NULL pointer dereference in sanitycheck()\n\nIf due to a memory allocation failure mock_chain() returns NULL, it is\npassed to dma_fence_enable_sw_signaling() resulting in NULL pointer\ndereference there.\n\nCall dma_fence_enable_sw_signaling() only if mock_chain() succeeds.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: mvm: pick the version of SESSION_PROTECTION_NOTIF\n\nWhen we want to know whether we should look for the mac_id or the\nlink_id in struct iwl_mvm_session_prot_notif, we should look at the\nversion of SESSION_PROTECTION_NOTIF.\n\nThis causes WARNINGs:\n\nWARNING: CPU: 0 PID: 11403 at drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959 iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]\nRIP: 0010:iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]\nCode: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41 c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff <0f> 0b e9 1c fe ff ff 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90\nRSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff9ae63a361000 RCX: ffff9ae4a98b60d4\nRDX: ffff9ae4588499c0 RSI: 0000000000000305 RDI: ffff9ae4a98b6358\nRBP: ffffb4bb00003d68 R08: 0000000000000003 R09: 0000000000000010\nR10: ffffb4bb00003d00 R11: 000000000000000f R12: ffff9ae441399050\nR13: ffff9ae4761329e8 R14: 0000000000000001 R15: 0000000000000000\nFS: 0000000000000000(0000) GS:ffff9ae7af400000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055fb75680018 CR3: 00000003dae32006 CR4: 0000000000f70ef0\nPKRU: 55555554\nCall Trace:\n <IRQ>\n ? show_regs+0x69/0x80\n ? __warn+0x8d/0x150\n ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]\n ? report_bug+0x196/0x1c0\n ? handle_bug+0x45/0x80\n ? exc_invalid_op+0x1c/0xb0\n ? asm_exc_invalid_op+0x1f/0x30\n ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]\n iwl_mvm_rx_common+0x115/0x340 [iwlmvm]\n iwl_mvm_rx_mq+0xa6/0x100 [iwlmvm]\n iwl_pcie_rx_handle+0x263/0xa10 [iwlwifi]\n iwl_pcie_napi_poll_msix+0x32/0xd0 [iwlwifi]

In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: t7xx: Split 64bit accesses to fix alignment issues\n\nSome of the registers are aligned on a 32bit boundary, causing\nalignment faults on 64bit platforms.\n\n Unable to handle kernel paging request at virtual address ffffffc084a1d004\n Mem abort info:\n ESR = 0x0000000096000061\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x21: alignment fault\n Data abort info:\n ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000\n CM = 0, WnR = 1, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000046ad6000\n [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711\n Internal error: Oops: 0000000096000061 [#1] SMP\n Modules linked in: mtk_t7xx(+) qcserial pppoe ppp_async option nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) iwlwifi(O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm cdc_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv\n md5 geniv des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys trusted\n CPU: 3 PID: 5266 Comm: kworker/u9:1 Tainted: G O 6.6.22 #0\n Hardware name: Bananapi BPI-R4 (DT)\n Workqueue: md_hk_wq t7xx_fsm_uninit [mtk_t7xx]\n pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx]\n lr : t7xx_cldma_start+0xac/0x13c [mtk_t7xx]\n sp : ffffffc085d63d30\n x29: ffffffc085d63d30 x28: 0000000000000000 x27: 0000000000000000\n x26: 0000000000000000 x25: ffffff80c804f2c0 x24: ffffff80ca196c05\n x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128\n x20: 0000000000000001 x19: ffffff80c814b080 x18: 0000000000000014\n x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68\n x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffffff80ca1ef6b4 x7 : ffffff80c814b818 x6 : 0000000000000018\n x5 : 0000000000000870 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000010a947000 x1 : ffffffc084a1d004 x0 : ffffffc084a1d004\n Call trace:\n t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx]\n t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx]\n process_one_work+0x154/0x2a0\n worker_thread+0x2ac/0x488\n kthread+0xe0/0xec\n ret_from_fork+0x10/0x20\n Code: f9400800 91001000 8b214001 d50332bf (f9000022)\n ---[ end trace 0000000000000000 ]---\n\nThe inclusion of io-64-nonatomic-lo-hi.h indicates that all 64bit\naccesses can be replaced by pairs of nonatomic 32bit access. Fix\nalignment by forcing all accesses to be 32bit on 64bit platforms.

In the Linux kernel, the following vulnerability has been resolved:\n\nmlxbf_gige: call request_irq() after NAPI initialized\n\nThe mlxbf_gige driver encounters a NULL pointer exception in\nmlxbf_gige_open() when kdump is enabled. The sequence to reproduce\nthe exception is as follows:\na) enable kdump\nb) trigger kdump via "echo c > /proc/sysrq-trigger"\nc) kdump kernel executes\nd) kdump kernel loads mlxbf_gige module\ne) the mlxbf_gige module runs its open() as the\n the "oob_net0" interface is brought up\nf) mlxbf_gige module will experience an exception\n during its open(), something like:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Mem abort info:\n ESR = 0x0000000086000004\n EC = 0x21: IABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\n user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000\n [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n Internal error: Oops: 0000000086000004 [#1] SMP\n CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu\n Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024\n pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : 0x0\n lr : __napi_poll+0x40/0x230\n sp : ffff800008003e00\n x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff\n x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8\n x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000\n x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000\n x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0\n x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c\n x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398\n x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2\n x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100\n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238\n Call trace:\n 0x0\n net_rx_action+0x178/0x360\n __do_softirq+0x15c/0x428\n __irq_exit_rcu+0xac/0xec\n irq_exit+0x18/0x2c\n handle_domain_irq+0x6c/0xa0\n gic_handle_irq+0xec/0x1b0\n call_on_irq_stack+0x20/0x2c\n do_interrupt_handler+0x5c/0x70\n el1_interrupt+0x30/0x50\n el1h_64_irq_handler+0x18/0x2c\n el1h_64_irq+0x7c/0x80\n __setup_irq+0x4c0/0x950\n request_threaded_irq+0xf4/0x1bc\n mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige]\n mlxbf_gige_open+0x5c/0x170 [mlxbf_gige]\n __dev_open+0x100/0x220\n __dev_change_flags+0x16c/0x1f0\n dev_change_flags+0x2c/0x70\n do_setlink+0x220/0xa40\n __rtnl_newlink+0x56c/0x8a0\n rtnl_newlink+0x58/0x84\n rtnetlink_rcv_msg+0x138/0x3c4\n netlink_rcv_skb+0x64/0x130\n rtnetlink_rcv+0x20/0x30\n netlink_unicast+0x2ec/0x360\n netlink_sendmsg+0x278/0x490\n __sock_sendmsg+0x5c/0x6c\n ____sys_sendmsg+0x290/0x2d4\n ___sys_sendmsg+0x84/0xd0\n __sys_sendmsg+0x70/0xd0\n __arm64_sys_sendmsg+0x2c/0x40\n invoke_syscall+0x78/0x100\n el0_svc_common.constprop.0+0x54/0x184\n do_el0_svc+0x30/0xac\n el0_svc+0x48/0x160\n el0t_64_sync_handler+0xa4/0x12c\n el0t_64_sync+0x1a4/0x1a8\n Code: bad PC value\n ---[ end trace 7d1c3f3bf9d81885 ]---\n Kernel panic - not syncing: Oops: Fatal exception in interrupt\n Kernel Offset: 0x2870a7a00000 from 0xffff800008000000\n PHYS_OFFSET: 0x80000000\n CPU features: 0x0,000005c1,a3332a5a\n Memory Limit: none\n ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---\n\nThe exception happens because there is a pending RX interrupt before the\ncall to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires\nimmediately after this request_irq() completes. The RX IRQ handler runs\n"napi_schedule()" before NAPI is fully initialized via "netif_napi_add()"\nand "napi_enable()", both which happen later in the open() logic.\n\nThe logic in mlxbf_gige_open() must fully initialize NAPI before any calls\nto request_irq() execute.

In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Protect against int overflow for stack access size\n\nThis patch re-introduces protection against the size of access to stack\nmemory being negative; the access size can appear negative as a result\nof overflowing its signed int representation. This should not actually\nhappen, as there are other protections along the way, but we should\nprotect against it anyway. One code path was missing such protections\n(fixed in the previous patch in the series), causing out-of-bounds array\naccesses in check_stack_range_initialized(). This patch causes the\nverification of a program with such a non-sensical access size to fail.\n\nThis check used to exist in a more indirect way, but was inadvertendly\nremoved in a833a17aeac7.

In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix kernel panic on unknown packet types\n\nIn the very rare case where a packet type is unknown to the driver,\nidpf_rx_process_skb_fields would return early without calling\neth_type_trans to set the skb protocol / the network layer handler.\nThis is especially problematic if tcpdump is running when such a\npacket is received, i.e. it would cause a kernel panic.\n\nInstead, call eth_type_trans for every single packet, even when\nthe packet type is unknown.