ISHACK AI BOT

Huawei EulerOS: CVE-2024-50045: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [176.292101] Mem abort info: [176.292184] ESR = 0x0000000096000004 [176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [176.292530] SET = 0, FnV = 0 [176.292709] EA = 0, S1PTW = 0 [176.292862] FSC = 0x04: level 0 translation fault [176.293013] Data abort info: [176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [176.296314] Hardware name: linux,dummy-virt (DT) [176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [176.297636] sp : ffff800080003630 [176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [176.300889] Call trace: [176.301123]br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [176.301411]br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [176.301703]nf_hook_slow+0x48/0x124 [176.302060]br_forward_finish+0xc8/0xe8 [bridge] [176.302371]br_nf_hook_thresh+0x124/0x134 [br_netfilter] [176.302605]br_nf_forward_finish+0x118/0x22c [br_netfilter] [176.302824]br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [176.303136]br_nf_forward+0x2b8/0x4e0 [br_netfilter] [176.303359]nf_hook_slow+0x48/0x124 [176.303 ---truncated--- Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-50045 CVE - 2024-50045 EulerOS-SA-2025-1192

Ubuntu: (CVE-2022-48952): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 References https://attackerkb.com/topics/cve-2022-48952 CVE - 2022-48952 https://git.kernel.org/linus/19098934f910b4d47cb30251dd39ffa57bef9523 https://git.kernel.org/stable/c/19098934f910b4d47cb30251dd39ffa57bef9523 https://git.kernel.org/stable/c/3e9c395ef2d52975b2c2894d2da09d6db2958bc6 https://git.kernel.org/stable/c/a4997bae1b5b012c8a6e2643e26578a7bc2cae36 https://git.kernel.org/stable/c/cb7323ece786f243f6d6ccf2e5b2b27b736bdc04 https://www.cve.org/CVERecord?id=CVE-2022-48952 View more

Ubuntu: (CVE-2022-48969): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-4 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-iot ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2022-48969 CVE - 2022-48969 https://git.kernel.org/linus/d50b7914fae04d840ce36491d22133070b18cca9 https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9 https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050 https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84 https://www.cve.org/CVERecord?id=CVE-2022-48969 View more

Ubuntu: (CVE-2022-48949): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:C/I:N/A:N) Published 10/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-4 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-iot ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2022-48949 CVE - 2022-48949 https://git.kernel.org/linus/de5dc44370fbd6b46bd7f1a1e00369be54a041c8 https://git.kernel.org/stable/c/367e1e3399dbc56fc669740c4ab60e35da632b0e https://git.kernel.org/stable/c/51fd5ede7ed42f272682a0c33d6f0767b3484a3d https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4 https://git.kernel.org/stable/c/c383c7c35c7bc15e07a04eefa060a8a80cbeae29 https://git.kernel.org/stable/c/c581439a977545d61849a72e8ed631cfc8a2a3c1 https://git.kernel.org/stable/c/de5dc44370fbd6b46bd7f1a1e00369be54a041c8 https://git.kernel.org/stable/c/ef1d739dd1f362aec081278ff92f943c31eb177a https://git.kernel.org/stable/c/f2479c3daaabccbac6c343a737615d0c595c6dc4 https://www.cve.org/CVERecord?id=CVE-2022-48949 View more

Ubuntu: (CVE-2022-48961): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix unbalanced fwnode reference count in mdio_device_release() There is warning report about of_node refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly. After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 References https://attackerkb.com/topics/cve-2022-48961 CVE - 2022-48961 https://git.kernel.org/linus/cb37617687f2bfa5b675df7779f869147c9002bd https://git.kernel.org/stable/c/16854177745a5648f8ec322353b432e18460f43a https://git.kernel.org/stable/c/a5c6de1a6656b8cc6bce7cb3d9874dd7df4968c3 https://git.kernel.org/stable/c/cb37617687f2bfa5b675df7779f869147c9002bd https://www.cve.org/CVERecord?id=CVE-2022-48961

Ubuntu: (CVE-2022-48967): linux vulnerability Severity 6 CVSS (AV:L/AC:L/Au:S/C:N/I:C/A:C) Published 10/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks. Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-aws-5-4 ubuntu-upgrade-linux-aws-fips ubuntu-upgrade-linux-aws-hwe ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-4-15 ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-5-4 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-azure-fips ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-fips ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-4-15 ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gcp-5-4 ubuntu-upgrade-linux-gcp-fips ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-hwe-5-4 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-ibm-5-4 ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-iot ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-oracle-5-4 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-raspi-5-4 ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 ubuntu-upgrade-linux-xilinx-zynqmp References https://attackerkb.com/topics/cve-2022-48967 CVE - 2022-48967 https://git.kernel.org/linus/e329e71013c9b5a4535b099208493c7826ee4a64 https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9 https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2 https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714 https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191 https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750 https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c https://git.kernel.org/stable/c/e329e71013c9b5a4535b099208493c7826ee4a64 https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a79cefae https://www.cve.org/CVERecord?id=CVE-2022-48967 View more

Ubuntu: (CVE-2022-48965): linux vulnerability Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/21/2024 Added 11/19/2024 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: gpio/rockchip: fix refcount leak in rockchip_gpiolib_register() The node returned by of_get_parent() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the end of of_pinctrl_get(). Solution(s) ubuntu-upgrade-linux ubuntu-upgrade-linux-aws ubuntu-upgrade-linux-aws-5-15 ubuntu-upgrade-linux-azure ubuntu-upgrade-linux-azure-5-15 ubuntu-upgrade-linux-azure-fde ubuntu-upgrade-linux-azure-fde-5-15 ubuntu-upgrade-linux-bluefield ubuntu-upgrade-linux-gcp ubuntu-upgrade-linux-gcp-5-15 ubuntu-upgrade-linux-gke ubuntu-upgrade-linux-gkeop ubuntu-upgrade-linux-gkeop-5-15 ubuntu-upgrade-linux-hwe-5-15 ubuntu-upgrade-linux-ibm ubuntu-upgrade-linux-intel-iot-realtime ubuntu-upgrade-linux-intel-iotg ubuntu-upgrade-linux-intel-iotg-5-15 ubuntu-upgrade-linux-kvm ubuntu-upgrade-linux-lowlatency ubuntu-upgrade-linux-lowlatency-hwe-5-15 ubuntu-upgrade-linux-nvidia ubuntu-upgrade-linux-oracle ubuntu-upgrade-linux-oracle-5-15 ubuntu-upgrade-linux-raspi ubuntu-upgrade-linux-realtime ubuntu-upgrade-linux-riscv-5-15 References https://attackerkb.com/topics/cve-2022-48965 CVE - 2022-48965 https://git.kernel.org/linus/63ff545af73f759d1bd04198af8ed8577fb739fc https://git.kernel.org/stable/c/033c79b7ee8a7bf1c1a13ac3addc91184425cbae https://git.kernel.org/stable/c/5cb8f1a784fd6115be58282fe15105572319d8be https://git.kernel.org/stable/c/63ff545af73f759d1bd04198af8ed8577fb739fc https://www.cve.org/CVERecord?id=CVE-2022-48965

Amazon Linux 2023: CVE-2024-47745: Important priority package update for kernel Severity 4 CVSS (AV:L/AC:H/Au:S/C:C/I:N/A:N) Published 10/21/2024 Created 02/05/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks] Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-124-134-200 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-47745 CVE - 2024-47745 https://alas.aws.amazon.com/AL2023/ALAS-2025-809.html

Amazon Linux 2023: CVE-2024-49983: Important priority package update for kernel Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 02/05/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-115-126-197 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-49983 CVE - 2024-49983 https://alas.aws.amazon.com/AL2023/ALAS-2025-794.html

Amazon Linux 2023: CVE-2024-49889: Important priority package update for kernel Severity 6 CVSS (AV:L/AC:L/Au:M/C:C/I:C/A:C) Published 10/21/2024 Created 02/05/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-115-126-197 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-49889 CVE - 2024-49889 https://alas.aws.amazon.com/AL2023/ALAS-2025-794.html

Huawei EulerOS: CVE-2024-47742: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 01/15/2025 Added 01/14/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-47742 CVE - 2024-47742 EulerOS-SA-2025-1024

Huawei EulerOS: CVE-2024-47701: kernel security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 01/15/2025 Added 01/14/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK> Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-47701 CVE - 2024-47701 EulerOS-SA-2025-1024

Debian: CVE-2024-49856: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49856 CVE - 2024-49856 DLA-4008-1

Debian: CVE-2024-47710: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47710 CVE - 2024-47710 DLA-4008-1

Debian: CVE-2024-47739: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47739 CVE - 2024-47739 DLA-4008-1

Debian: CVE-2024-47713: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-47713 CVE - 2024-47713 DLA-4008-1

Debian: CVE-2024-49878: linux, linux-6.1 -- security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 11/12/2024 Added 11/11/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X".This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource.This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected.However, the error code is wrong.It should be "Operation not permitted" instead of "Bad address".More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly.Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue.During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows.In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource.So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources.Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above.To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources.So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM". Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49878 CVE - 2024-49878 DLA-4008-1

Huawei EulerOS: CVE-2024-50047: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [194.196391] ================================================================== [194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [194.197707] [194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [194.200032] Call Trace: [194.200191]<TASK> [194.200327]dump_stack_lvl+0x4e/0x70 [194.200558]? gf128mul_4k_lle+0xc1/0x110 [194.200809]print_report+0x174/0x505 [194.201040]? __pfx__raw_spin_lock_irqsave+0x10/0x10 [194.201352]? srso_return_thunk+0x5/0x5f [194.201604]? __virt_addr_valid+0xdf/0x1c0 [194.201868]? gf128mul_4k_lle+0xc1/0x110 [194.202128]kasan_report+0xc8/0x150 [194.202361]? gf128mul_4k_lle+0xc1/0x110 [194.202616]gf128mul_4k_lle+0xc1/0x110 [194.202863]ghash_update+0x184/0x210 [194.203103]shash_ahash_update+0x184/0x2a0 [194.203377]? __pfx_shash_ahash_update+0x10/0x10 [194.203651]? srso_return_thunk+0x5/0x5f [194.203877]? crypto_gcm_init_common+0x1ba/0x340 [194.204142]gcm_hash_assoc_remain_continue+0x10a/0x140 [194.204434]crypt_message+0xec1/0x10a0 [cifs] [194.206489]? __pfx_crypt_message+0x10/0x10 [cifs] [194.208507]? srso_return_thunk+0x5/0x5f [194.209205]? srso_return_thunk+0x5/0x5f [194.209925]? srso_return_thunk+0x5/0x5f [194.210443]? srso_return_thunk+0x5/0x5f [194.211037]decrypt_raw_data+0x15f/0x250 [cifs] [194.212906]? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [194.214670]? srso_return_thunk+0x5/0x5f [194.215193]smb2_decrypt_offload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()). Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it's always going to be a synchronous operation. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-50047 CVE - 2024-50047 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2022-49000: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/15/2025 Added 01/14/2025 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in has_external_pci() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-49000 CVE - 2022-49000 EulerOS-SA-2025-1024

Huawei EulerOS: CVE-2024-50038: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing.As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git. Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-50038 CVE - 2024-50038 EulerOS-SA-2025-1192

Huawei EulerOS: CVE-2022-49002: kernel security update Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/15/2025 Added 01/14/2025 Modified 01/28/2025 Description In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak. Solution(s) huawei-euleros-2_0_sp10-upgrade-kernel huawei-euleros-2_0_sp10-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp10-upgrade-kernel-tools huawei-euleros-2_0_sp10-upgrade-kernel-tools-libs huawei-euleros-2_0_sp10-upgrade-python3-perf References https://attackerkb.com/topics/cve-2022-49002 CVE - 2022-49002 EulerOS-SA-2025-1024

Huawei EulerOS: CVE-2024-50039: kernel security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/12/2025 Added 02/11/2025 Modified 02/11/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 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 <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov%rdx,%rsi f: 48 29 d0 sub%rdx,%rax 12: 48 8b 91 c0 01 00 00 mov0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl$0x3,%rax 1d: 48 01 c2 add%rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle0xffffffffffffffe7 27: 48 8b 3a mov(%rdx),%rdi 2a:* 4c 8b 07 mov(%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov%r8,(%rdx) 30: 49 89 50 08 mov%rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ... Code starting with the faulting instruction =========================================== 0: 4c 8b 07 mov(%rdi),%r8 3: 4c 89 02 mov%r8,(%rdx) 6: 49 89 50 08 mov%rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS:00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459]<TASK> [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated--- Solution(s) huawei-euleros-2_0_sp12-upgrade-bpftool huawei-euleros-2_0_sp12-upgrade-kernel huawei-euleros-2_0_sp12-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp12-upgrade-kernel-tools huawei-euleros-2_0_sp12-upgrade-kernel-tools-libs huawei-euleros-2_0_sp12-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-50039 CVE - 2024-50039 EulerOS-SA-2025-1192

Amazon Linux 2023: CVE-2024-49861: Important priority package update for kernel Severity 4 CVSS (AV:L/AC:L/Au:M/C:N/I:N/A:C) Published 10/21/2024 Created 02/05/2025 Added 02/14/2025 Modified 02/14/2025 Description In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta-&gt;raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it&apos;s okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *&lt;ptr&gt; = val. The .arg*_size has been initialized reflecting the actual sizeof(*&lt;ptr&gt;). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *&lt;ptr&gt; = val. Solution(s) amazon-linux-2023-upgrade-bpftool amazon-linux-2023-upgrade-bpftool-debuginfo amazon-linux-2023-upgrade-kernel amazon-linux-2023-upgrade-kernel-debuginfo amazon-linux-2023-upgrade-kernel-debuginfo-common-aarch64 amazon-linux-2023-upgrade-kernel-debuginfo-common-x86-64 amazon-linux-2023-upgrade-kernel-devel amazon-linux-2023-upgrade-kernel-headers amazon-linux-2023-upgrade-kernel-libbpf amazon-linux-2023-upgrade-kernel-libbpf-devel amazon-linux-2023-upgrade-kernel-libbpf-static amazon-linux-2023-upgrade-kernel-livepatch-6-1-124-134-200 amazon-linux-2023-upgrade-kernel-modules-extra amazon-linux-2023-upgrade-kernel-modules-extra-common amazon-linux-2023-upgrade-kernel-tools amazon-linux-2023-upgrade-kernel-tools-debuginfo amazon-linux-2023-upgrade-kernel-tools-devel amazon-linux-2023-upgrade-perf amazon-linux-2023-upgrade-perf-debuginfo amazon-linux-2023-upgrade-python3-perf amazon-linux-2023-upgrade-python3-perf-debuginfo References https://attackerkb.com/topics/cve-2024-49861 CVE - 2024-49861 https://alas.aws.amazon.com/AL2023/ALAS-2025-809.html

VMware Photon OS: CVE-2024-49983 Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-49983 CVE - 2024-49983

VMware Photon OS: CVE-2024-49978 Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 01/21/2025 Added 01/20/2025 Modified 02/04/2025 Description In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Solution(s) vmware-photon_os_update_tdnf References https://attackerkb.com/topics/cve-2024-49978 CVE - 2024-49978