Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/ct: prevent UAF in send_recv()<br /> <br /> Ensure we serialize with completion side to prevent UAF with fence going<br /> out of scope on the stack, since we have no clue if it will fire after<br /> the timeout before we can erase from the xa. Also we have some dependent<br /> loads and stores for which we need the correct ordering, and we lack the<br /> needed barriers. Fix this by grabbing the ct-&gt;lock after the wait, which<br /> is also held by the completion side.<br /> <br /> v2 (Badal):<br /> - Also print done after acquiring the lock and seeing timeout.<br /> <br /> (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC<br /> <br /> Eric report a panic on IPPROTO_SMC, and give the facts<br /> that when INET_PROTOSW_ICSK was set, icsk-&gt;icsk_sync_mss must be set too.<br /> <br /> Bug: Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000086000005<br /> EC = 0x21: IABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x05: level 1 translation fault<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000<br /> [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003,<br /> pud=0000000000000000<br /> Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted<br /> 6.11.0-rc7-syzkaller-g5f5673607153 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine,<br /> BIOS Google 08/06/2024<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : 0x0<br /> lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910<br /> sp : ffff80009b887a90<br /> x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000<br /> x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00<br /> x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000<br /> x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee<br /> x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001<br /> x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003<br /> x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000<br /> x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000<br /> Call trace:<br /> 0x0<br /> netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000<br /> smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593<br /> smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973<br /> security_socket_post_create+0x94/0xd4 security/security.c:4425<br /> __sock_create+0x4c8/0x884 net/socket.c:1587<br /> sock_create net/socket.c:1622 [inline]<br /> __sys_socket_create net/socket.c:1659 [inline]<br /> __sys_socket+0x134/0x340 net/socket.c:1706<br /> __do_sys_socket net/socket.c:1720 [inline]<br /> __se_sys_socket net/socket.c:1718 [inline]<br /> __arm64_sys_socket+0x7c/0x94 net/socket.c:1718<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712<br /> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> Code: ???????? ???????? ???????? ???????? (????????)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This patch add a toy implementation that performs a simple return to<br /> prevent such panic. This is because MSS can be set in sock_create_kern<br /> or smc_setsockopt, similar to how it&amp;#39;s done in AF_SMC. However, for<br /> AF_SMC, there is currently no way to synchronize MSS within<br /> __sys_connect_file. This toy implementation lays the groundwork for us<br /> to support such feature for IPPROTO_SMC in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-dma: Only cleanup deferred I/O if necessary<br /> <br /> Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if<br /> necessary") initializes deferred I/O only if it is used.<br /> drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()<br /> unconditionally with struct fb_info.fbdefio == NULL. KASAN with the<br /> out-of-tree Apple silicon display driver posts following warning from<br /> __flush_work() of a random struct work_struct instead of the expected<br /> NULL pointer derefs.<br /> <br /> [ 22.053799] ------------[ cut here ]------------<br /> [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580<br /> [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram<br /> [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev<br /> [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)<br /> [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 22.078567] pc : __flush_work+0x4d8/0x580<br /> [ 22.079471] lr : __flush_work+0x54/0x580<br /> [ 22.080345] sp : ffffc000836ef820<br /> [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128<br /> [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358<br /> [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470<br /> [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000<br /> [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005<br /> [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000<br /> [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e<br /> [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001<br /> [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020<br /> [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000<br /> [ 22.096955] Call trace:<br /> [ 22.097505] __flush_work+0x4d8/0x580<br /> [ 22.098330] flush_delayed_work+0x80/0xb8<br /> [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130<br /> [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper]<br /> [ 22.101559] unregister_framebuffer+0x210/0x2f0<br /> [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60<br /> [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper]<br /> [ 22.105147] drm_client_dev_unregister+0x1cc/0x230<br /> [ 22.106217] drm_dev_unregister+0x58/0x570<br /> [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm]<br /> [ 22.108199] component_del+0x1f8/0x3a8<br /> [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp]<br /> [ 22.110357] platform_shutdown+0x70/0x90<br /> [ 22.111219] device_shutdown+0x368/0x4d8<br /> [ 22.112095] kernel_restart+0x6c/0x1d0<br /> [ 22.112946] __arm64_sys_reboot+0x1c8/0x328<br /> [ 22.113868] invoke_syscall+0x78/0x1a8<br /> [ 22.114703] do_el0_svc+0x124/0x1a0<br /> [ 22.115498] el0_svc+0x3c/0xe0<br /> [ 22.116181] el0t_64_sync_handler+0x70/0xc0<br /> [ 22.117110] el0t_64_sync+0x190/0x198<br /> [ 22.117931] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Stop the active perfmon before being destroyed<br /> <br /> When running `kmscube` with one or more performance monitors enabled<br /> via `GALLIUM_HUD`, the following kernel panic can occur:<br /> <br /> [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4<br /> [ 55.008368] Mem abort info:<br /> [ 55.008377] ESR = 0x0000000096000005<br /> [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 55.008402] SET = 0, FnV = 0<br /> [ 55.008412] EA = 0, S1PTW = 0<br /> [ 55.008421] FSC = 0x05: level 1 translation fault<br /> [ 55.008434] Data abort info:<br /> [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000<br /> [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper<br /> gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb<br /> drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight<br /> [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1<br /> [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)<br /> [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608<br /> [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608<br /> [ 55.008895] sp : ffffffc080673cf0<br /> [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28<br /> [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148<br /> [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38<br /> [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000<br /> [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90<br /> [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0<br /> [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04<br /> [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857<br /> [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470<br /> [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470<br /> [ 55.013292] Call trace:<br /> [ 55.013959] __mutex_lock.constprop.0+0x90/0x608<br /> [ 55.014646] __mutex_lock_slowpath+0x1c/0x30<br /> [ 55.015317] mutex_lock+0x50/0x68<br /> [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d]<br /> [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d]<br /> [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched]<br /> [ 55.017921] kthread+0x11c/0x128<br /> [ 55.018554] ret_from_fork+0x10/0x20<br /> [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401)<br /> [ 55.019776] ---[ end trace 0000000000000000 ]---<br /> [ 55.020411] note: v3d_bin[166] exited with preempt_count 1<br /> <br /> This issue arises because, upon closing the file descriptor (which happens<br /> when we interrupt `kmscube`), the active performance monitor is not<br /> stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`,<br /> the active performance monitor&amp;#39;s pointer (`v3d-&gt;active_perfmon`) is still<br /> retained.<br /> <br /> If `kmscube` is run again, the driver will attempt to stop the active<br /> performance monitor using the stale pointer in `v3d-&gt;active_perfmon`.<br /> However, this pointer is no longer valid because the previous process has<br /> already terminated, and all performance monitors associated with it have<br /> been destroyed and freed.<br /> <br /> To fix this, when the active performance monitor belongs to a given<br /> process, explicitly stop it before destroying and freeing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slip: make slhc_remember() more robust against malicious packets<br /> <br /> syzbot found that slhc_remember() was missing checks against<br /> malicious packets [1].<br /> <br /> slhc_remember() only checked the size of the packet was at least 20,<br /> which is not good enough.<br /> <br /> We need to make sure the packet includes the IPv4 and TCP header<br /> that are supposed to be carried.<br /> <br /> Add iph and th pointers to make the code more readable.<br /> <br /> [1]<br /> <br /> BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666<br /> slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666<br /> ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455<br /> ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]<br /> ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212<br /> ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327<br /> pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379<br /> sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113<br /> __release_sock+0x1da/0x330 net/core/sock.c:3072<br /> release_sock+0x6b/0x250 net/core/sock.c:3626<br /> pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903<br /> sock_sendmsg_nosec net/socket.c:729 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:744<br /> ____sys_sendmsg+0x903/0xb60 net/socket.c:2602<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656<br /> __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742<br /> __do_sys_sendmmsg net/socket.c:2771 [inline]<br /> __se_sys_sendmmsg net/socket.c:2768 [inline]<br /> __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768<br /> x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4091 [inline]<br /> slab_alloc_node mm/slub.c:4134 [inline]<br /> kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587<br /> __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678<br /> alloc_skb include/linux/skbuff.h:1322 [inline]<br /> sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732<br /> pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867<br /> sock_sendmsg_nosec net/socket.c:729 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:744<br /> ____sys_sendmsg+0x903/0xb60 net/socket.c:2602<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656<br /> __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742<br /> __do_sys_sendmmsg net/socket.c:2771 [inline]<br /> __se_sys_sendmmsg net/socket.c:2768 [inline]<br /> __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768<br /> x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: fix ppp_async_encode() illegal access<br /> <br /> syzbot reported an issue in ppp_async_encode() [1]<br /> <br /> In this case, pppoe_sendmsg() is called with a zero size.<br /> Then ppp_async_encode() is called with an empty skb.<br /> <br /> BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]<br /> BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675<br /> ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]<br /> ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675<br /> ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634<br /> ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]<br /> ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304<br /> pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379<br /> sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113<br /> __release_sock+0x1da/0x330 net/core/sock.c:3072<br /> release_sock+0x6b/0x250 net/core/sock.c:3626<br /> pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903<br /> sock_sendmsg_nosec net/socket.c:729 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:744<br /> ____sys_sendmsg+0x903/0xb60 net/socket.c:2602<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656<br /> __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742<br /> __do_sys_sendmmsg net/socket.c:2771 [inline]<br /> __se_sys_sendmmsg net/socket.c:2768 [inline]<br /> __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768<br /> x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4092 [inline]<br /> slab_alloc_node mm/slub.c:4135 [inline]<br /> kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587<br /> __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678<br /> alloc_skb include/linux/skbuff.h:1322 [inline]<br /> sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732<br /> pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867<br /> sock_sendmsg_nosec net/socket.c:729 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:744<br /> ____sys_sendmsg+0x903/0xb60 net/socket.c:2602<br /> ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656<br /> __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742<br /> __do_sys_sendmmsg net/socket.c:2771 [inline]<br /> __se_sys_sendmmsg net/socket.c:2768 [inline]<br /> __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768<br /> x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not delay dst_entries_add() in dst_release()<br /> <br /> dst_entries_add() uses per-cpu data that might be freed at netns<br /> dismantle from ip6_route_net_exit() calling dst_entries_destroy()<br /> <br /> Before ip6_route_net_exit() can be called, we release all<br /> the dsts associated with this netns, via calls to dst_release(),<br /> which waits an rcu grace period before calling dst_destroy()<br /> <br /> dst_entries_add() use in dst_destroy() is racy, because<br /> dst_entries_destroy() could have been called already.<br /> <br /> Decrementing the number of dsts must happen sooner.<br /> <br /> Notes:<br /> <br /> 1) in CONFIG_XFRM case, dst_destroy() can call<br /> dst_release_immediate(child), this might also cause UAF<br /> if the child does not have DST_NOCOUNT set.<br /> IPSEC maintainers might take a look and see how to address this.<br /> <br /> 2) There is also discussion about removing this count of dst,<br /> which might happen in future kernels.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xtables: avoid NFPROTO_UNSPEC where needed<br /> <br /> syzbot managed to call xt_cluster match via ebtables:<br /> <br /> WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780<br /> [..]<br /> ebt_do_table+0x174b/0x2a40<br /> <br /> Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet<br /> processing. As this is only useful to restrict locally terminating<br /> TCP/UDP traffic, register this for ipv4 and ipv6 family only.<br /> <br /> Pablo points out that this is a general issue, direct users of the<br /> set/getsockopt interface can call into targets/matches that were only<br /> intended for use with ip(6)tables.<br /> <br /> Check all UNSPEC matches and targets for similar issues:<br /> <br /> - matches and targets are fine except if they assume skb_network_header()<br /> is valid -- this is only true when called from inet layer: ip(6) stack<br /> pulls the ip/ipv6 header into linear data area.<br /> - targets that return XT_CONTINUE or other xtables verdicts must be<br /> restricted too, they are incompatbile with the ebtables traverser, e.g.<br /> EBT_CONTINUE is a completely different value than XT_CONTINUE.<br /> <br /> Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as<br /> they are provided for use by ip(6)tables.<br /> <br /> The MARK target is also used by arptables, so register for NFPROTO_ARP too.<br /> <br /> While at it, bail out if connbytes fails to enable the corresponding<br /> conntrack family.<br /> <br /> This change passes the selftests in iptables.git.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: accept TCA_STAB only for root qdisc<br /> <br /> Most qdiscs maintain their backlog using qdisc_pkt_len(skb)<br /> on the assumption it is invariant between the enqueue()<br /> and dequeue() handlers.<br /> <br /> Unfortunately syzbot can crash a host rather easily using<br /> a TBF + SFQ combination, with an STAB on SFQ [1]<br /> <br /> We can&amp;#39;t support TCA_STAB on arbitrary level, this would<br /> require to maintain per-qdisc storage.<br /> <br /> [1]<br /> [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 88.798611] #PF: supervisor read access in kernel mode<br /> [ 88.799014] #PF: error_code(0x0000) - not-present page<br /> [ 88.799506] PGD 0 P4D 0<br /> [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117<br /> [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq<br /> [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00<br /> All code<br /> ========<br /> 0: 0f b7 50 12 movzwl 0x12(%rax),%edx<br /> 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax<br /> b: 00<br /> c: 48 89 d6 mov %rdx,%rsi<br /> f: 48 29 d0 sub %rdx,%rax<br /> 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx<br /> 19: 48 c1 e0 03 shl $0x3,%rax<br /> 1d: 48 01 c2 add %rax,%rdx<br /> 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx)<br /> 25: 7e c0 jle 0xffffffffffffffe7<br /> 27: 48 8b 3a mov (%rdx),%rdi<br /> 2a:* 4c 8b 07 mov (%rdi),%r8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()<br /> <br /> This patch addresses an issue with improper reference count handling in the<br /> ice_sriov_set_msix_vec_count() function.<br /> <br /> First, the function calls ice_get_vf_by_id(), which increments the<br /> reference count of the vf pointer. If the subsequent call to<br /> ice_get_vf_vsi() fails, the function currently returns an error without<br /> decrementing the reference count of the vf pointer, leading to a reference<br /> count leak. The correct behavior, as implemented in this patch, is to<br /> decrement the reference count using ice_put_vf(vf) before returning an<br /> error when vsi is NULL.<br /> <br /> Second, the function calls ice_sriov_get_irqs(), which sets<br /> vf-&gt;first_vector_idx. If this call returns a negative value, indicating an<br /> error, the function returns an error without decrementing the reference<br /> count of the vf pointer, resulting in another reference count leak. The<br /> patch addresses this by adding a call to ice_put_vf(vf) before returning<br /> an error when vf-&gt;first_vector_idx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()<br /> <br /> This patch addresses a reference count handling issue in the<br /> ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(),<br /> which increments the reference count of the relevant resources. However,<br /> if the condition WARN_ON((!vsi || !vsi-&gt;netdev)) is met, the function<br /> currently returns an error without properly releasing the resources<br /> acquired by ice_dpll_get_pins(), leading to a reference count leak.<br /> <br /> To resolve this, the check has been moved to the top of the function. This<br /> ensures that the function verifies the state before any resources are<br /> acquired, avoiding the need for additional resource management in the<br /> error path.<br /> <br /> This bug was identified by an experimental static analysis tool developed<br /> by our team. The tool specializes in analyzing reference count operations<br /> and detecting potential issues where resources are not properly managed.<br /> In this case, the tool flagged the missing release operation as a<br /> potential problem, which led to the development of this patch.