Vulnerabilities

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 Minecraft mod "Command Block IDE" up to and including version 0.4.9, a missing authorization (CWE-862) allows any user to modify "function" files used by the game when installed on a dedicated server.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: Remove LED entry from LEDs list on unregister<br /> <br /> Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct<br /> ordering") correctly fixed a problem with using devm_ but missed<br /> removing the LED entry from the LEDs list.<br /> <br /> This cause kernel panic on specific scenario where the port for the PHY<br /> is torn down and up and the kmod for the PHY is removed.<br /> <br /> On setting the port down the first time, the assosiacted LEDs are<br /> correctly unregistered. The associated kmod for the PHY is now removed.<br /> The kmod is now added again and the port is now put up, the associated LED<br /> are registered again.<br /> On putting the port down again for the second time after these step, the<br /> LED list now have 4 elements. With the first 2 already unregistered<br /> previously and the 2 new one registered again.<br /> <br /> This cause a kernel panic as the first 2 element should have been<br /> removed.<br /> <br /> Fix this by correctly removing the element when LED is unregistered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: fnic: Move flush_work initialization out of if block<br /> <br /> After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a<br /> work queue"), it can happen that a work item is sent to an uninitialized<br /> work queue. This may has the effect that the item being queued is never<br /> actually queued, and any further actions depending on it will not<br /> proceed.<br /> <br /> The following warning is observed while the fnic driver is loaded:<br /> <br /> kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410<br /> kernel: <br /> kernel: queue_work_on+0x3a/0x50<br /> kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]<br /> kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24]<br /> kernel: __handle_irq_event_percpu+0x36/0x1a0<br /> kernel: handle_irq_event_percpu+0x30/0x70<br /> kernel: handle_irq_event+0x34/0x60<br /> kernel: handle_edge_irq+0x7e/0x1a0<br /> kernel: __common_interrupt+0x3b/0xb0<br /> kernel: common_interrupt+0x58/0xa0<br /> kernel: <br /> <br /> It has been observed that this may break the rediscovery of Fibre<br /> Channel devices after a temporary fabric failure.<br /> <br /> This patch fixes it by moving the work queue initialization out of<br /> an if block in fnic_probe().