ISHACK AI BOT 发布的所有帖子
-
Oracle Linux: CVE-2024-49952: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-49952: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:M/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK> Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49952 CVE - 2024-49952 ELSA-2024-12884
-
Debian: CVE-2024-50014: linux -- security update
Debian: CVE-2024-50014: linux -- security update Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/11/2025 Added 02/10/2025 Modified 02/10/2025 Description In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error().Unfortunately, at this point this spinlock has not been initialized yet.Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat. Solution(s) debian-upgrade-linux References https://attackerkb.com/topics/cve-2024-50014 CVE - 2024-50014 DSA-5860-1
-
Oracle Linux: CVE-2024-49924: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-49924: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb| set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49924 CVE - 2024-49924 ELSA-2024-12884
-
Debian: CVE-2024-49992: linux, linux-6.1 -- security update
Debian: CVE-2024-49992: linux, linux-6.1 -- security update Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/I:C/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: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/ Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-49992 CVE - 2024-49992 DLA-4008-1
-
Oracle Linux: CVE-2024-49892: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-49892: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49892 CVE - 2024-49892 ELSA-2024-12884
-
Debian: CVE-2024-50031: linux, linux-6.1 -- security update
Debian: CVE-2024-50031: 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: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959]__mutex_lock.constprop.0+0x90/0x608 [ 55.014646]__mutex_lock_slowpath+0x1c/0x30 [ 55.015317]mutex_lock+0x50/0x68 [ 55.015961]v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627]v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282]drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921]kthread+0x11c/0x128 [ 55.018554]ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Solution(s) debian-upgrade-linux debian-upgrade-linux-6-1 References https://attackerkb.com/topics/cve-2024-50031 CVE - 2024-50031 DLA-4008-1
-
Oracle Linux: CVE-2024-47685: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-47685: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:N/AC:L/Au:N/C:P/I:P/A:N) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated--- Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-47685 CVE - 2024-47685 ELSA-2024-12884
-
Oracle Linux: CVE-2024-50045: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-50045: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/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) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-50045 CVE - 2024-50045 ELSA-2024-12884
-
Oracle Linux: CVE-2024-49878: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-49878: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/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) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49878 CVE - 2024-49878 ELSA-2024-12884
-
Oracle Linux: CVE-2024-49998: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-49998: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 4 CVSS (AV:L/AC:H/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 02/12/2025 Added 02/10/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data.All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up). Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49998 CVE - 2024-49998 ELSA-2025-20095
-
Oracle Linux: CVE-2024-49868: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-49868: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 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 [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49868 CVE - 2024-49868 ELSA-2024-12884
-
Oracle Linux: CVE-2024-49950: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-49950: ELSA-2025-20095: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 7 CVSS (AV:A/AC:L/Au:M/C:C/I:C/A:C) Published 10/21/2024 Created 02/12/2025 Added 02/10/2025 Modified 02/13/2025 Description In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49950 CVE - 2024-49950 ELSA-2025-20095
-
Ubuntu: (Multiple Advisories) (CVE-2024-49886): Linux kernel vulnerabilities
Ubuntu: (Multiple Advisories) (CVE-2024-49886): Linux kernel vulnerabilities Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/18/2024 Modified 01/30/2025 Description In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: GE6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091]<TASK> [ 19.425448]dump_stack_lvl+0x5d/0x80 [ 19.426963]? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694]print_report+0x19d/0x52e [ 19.430206]? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837]? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539]kasan_report+0xf0/0x170 [ 19.435019]? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709]_isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379]? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910]isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573]? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263]? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797]cpuhp_invoke_callback+0x221/0xec0 [ 19.446337]cpuhp_thread_fun+0x21b/0x610 [ 19.447814]? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354]smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859]? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405]kthread+0x29c/0x350 [ 19.453817]? __pfx_kthread+0x10/0x10 [ 19.455253]ret_from_fork+0x31/0x70 [ 19.456685]? __pfx_kthread+0x10/0x10 [ 19.458114]ret_from_fork_asm+0x1a/0x30 [ 19.459573]</TASK> [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410]kasan_save_stack+0x30/0x50 [ 19.464788]kasan_save_track+0x14/0x30 [ 19.466139]__kasan_kmalloc+0xaa/0xb0 [ 19.467465]__kmalloc+0x1cd/0x470 [ 19.468748]isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233]isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670]do_one_initcall+0xa4/0x380 [ 19.472903]do_init_module+0x238/0x760 [ 19.474105]load_module+0x5239/0x6f00 [ 19.475285]init_module_from_file+0xd1/0x130 [ 19.476506]idempotent_init_module+0x23b/0x650 [ 19.477725]__x64_sys_finit_module+0xbe/0x130 [ 19.476506]idempotent_init_module+0x23b/0x650 [ 19.477725]__x64_sys_finit_module+0xbe/0x130 [ 19.478920]do_syscall_64+0x82/0x160 [ 19.480036]entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated--- Solution(s) ubuntu-upgrade-linux-image-5-15-0-1039-xilinx-zynqmp ubuntu-upgrade-linux-image-5-15-0-1056-gkeop ubuntu-upgrade-linux-image-5-15-0-1066-ibm ubuntu-upgrade-linux-image-5-15-0-1066-raspi ubuntu-upgrade-linux-image-5-15-0-1068-nvidia ubuntu-upgrade-linux-image-5-15-0-1068-nvidia-lowlatency ubuntu-upgrade-linux-image-5-15-0-1070-gke ubuntu-upgrade-linux-image-5-15-0-1070-kvm ubuntu-upgrade-linux-image-5-15-0-1071-intel-iotg ubuntu-upgrade-linux-image-5-15-0-1071-oracle ubuntu-upgrade-linux-image-5-15-0-1072-gcp ubuntu-upgrade-linux-image-5-15-0-1073-aws ubuntu-upgrade-linux-image-5-15-0-1078-azure ubuntu-upgrade-linux-image-5-15-0-127-generic ubuntu-upgrade-linux-image-5-15-0-127-generic-64k ubuntu-upgrade-linux-image-5-15-0-127-generic-lpae ubuntu-upgrade-linux-image-5-15-0-127-lowlatency ubuntu-upgrade-linux-image-5-15-0-127-lowlatency-64k ubuntu-upgrade-linux-image-aws ubuntu-upgrade-linux-image-aws-lts-22-04 ubuntu-upgrade-linux-image-azure ubuntu-upgrade-linux-image-azure-cvm ubuntu-upgrade-linux-image-azure-lts-22-04 ubuntu-upgrade-linux-image-gcp ubuntu-upgrade-linux-image-gcp-lts-22-04 ubuntu-upgrade-linux-image-generic ubuntu-upgrade-linux-image-generic-64k ubuntu-upgrade-linux-image-generic-64k-hwe-20-04 ubuntu-upgrade-linux-image-generic-hwe-20-04 ubuntu-upgrade-linux-image-generic-lpae ubuntu-upgrade-linux-image-generic-lpae-hwe-20-04 ubuntu-upgrade-linux-image-gke ubuntu-upgrade-linux-image-gke-5-15 ubuntu-upgrade-linux-image-gkeop ubuntu-upgrade-linux-image-gkeop-5-15 ubuntu-upgrade-linux-image-ibm ubuntu-upgrade-linux-image-intel ubuntu-upgrade-linux-image-intel-iotg ubuntu-upgrade-linux-image-kvm ubuntu-upgrade-linux-image-lowlatency ubuntu-upgrade-linux-image-lowlatency-64k ubuntu-upgrade-linux-image-lowlatency-64k-hwe-20-04 ubuntu-upgrade-linux-image-lowlatency-hwe-20-04 ubuntu-upgrade-linux-image-nvidia ubuntu-upgrade-linux-image-nvidia-lowlatency ubuntu-upgrade-linux-image-oem-20-04 ubuntu-upgrade-linux-image-oem-20-04b ubuntu-upgrade-linux-image-oem-20-04c ubuntu-upgrade-linux-image-oem-20-04d ubuntu-upgrade-linux-image-oracle ubuntu-upgrade-linux-image-oracle-lts-22-04 ubuntu-upgrade-linux-image-raspi ubuntu-upgrade-linux-image-raspi-nolpae ubuntu-upgrade-linux-image-virtual ubuntu-upgrade-linux-image-virtual-hwe-20-04 ubuntu-upgrade-linux-image-xilinx-zynqmp References https://attackerkb.com/topics/cve-2024-49886 CVE - 2024-49886 USN-7166-1 USN-7166-2 USN-7166-3 USN-7166-4 USN-7186-1 USN-7186-2 USN-7194-1 View more
-
Huawei EulerOS: CVE-2024-50058: kernel security update
Huawei EulerOS: CVE-2024-50058: 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: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. Solution(s) huawei-euleros-2_0_sp11-upgrade-bpftool huawei-euleros-2_0_sp11-upgrade-kernel huawei-euleros-2_0_sp11-upgrade-kernel-abi-stablelists huawei-euleros-2_0_sp11-upgrade-kernel-tools huawei-euleros-2_0_sp11-upgrade-kernel-tools-libs huawei-euleros-2_0_sp11-upgrade-python3-perf References https://attackerkb.com/topics/cve-2024-50058 CVE - 2024-50058 EulerOS-SA-2025-1159
-
Oracle Linux: CVE-2024-47699: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-47699: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-47699 CVE - 2024-47699 ELSA-2024-12884
-
Oracle Linux: CVE-2024-47712: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-47712: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed. Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-47712 CVE - 2024-47712 ELSA-2024-12884
-
Oracle Linux: CVE-2024-47713: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-47713: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/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) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-47713 CVE - 2024-47713 ELSA-2024-12884
-
Oracle Linux: CVE-2024-47701: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-47701: ELSA-2024-12884: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 6 CVSS (AV:L/AC:H/Au:M/C:C/I:C/A:C) Published 10/21/2024 Created 12/19/2024 Added 12/17/2024 Modified 01/23/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) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-47701 CVE - 2024-47701 ELSA-2024-12884
-
Oracle Linux: CVE-2024-47709: ELSA-2024-12868: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories)
Oracle Linux: CVE-2024-47709: ELSA-2024-12868: Unbreakable Enterprise kernel security update (IMPORTANT) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/11/2024 Added 12/09/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS:0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS:0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 </TASK> Solution(s) oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-47709 CVE - 2024-47709 ELSA-2024-12868 ELSA-2024-12884
-
Oracle Linux: CVE-2024-49949: ELSA-2024-10939: kernel security update (MODERATE) (Multiple Advisories)
Oracle Linux: CVE-2024-49949: ELSA-2024-10939:kernel security update (MODERATE) (Multiple Advisories) Severity 5 CVSS (AV:L/AC:L/Au:S/C:N/I:N/A:C) Published 10/21/2024 Created 12/14/2024 Added 12/12/2024 Modified 01/23/2025 Description In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:24 08and$0x8,%al 2:49 c1 e1 06shl$0x6,%r9 6:44 89 7c 24 18 mov%r15d,0x18(%rsp) b:45 31 ed xor%r13d,%r13d e:45 31 c0 xor%r8d,%r8d 11:31 ffxor%edi,%edi 13:89 44 24 14mov%eax,0x14(%rsp) 17:4c 03 8b 90 01 00 00 add0x190(%rbx),%r9 1e:eb 04jmp0x24 20:39 cacmp%ecx,%edx 22:73 37jae0x5b 24:4d 8b 39 mov(%r9),%r15 27:83 c7 01 add$0x1,%edi 2a:*49 8b 17 mov(%r15),%rdx<-- trapping instruction 2d:49 89 11 mov%rdx,(%r9) 30:41 8b 57 28mov0x28(%r15),%edx 34:45 8b 5f 34mov0x34(%r15),%r11d 38:49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f:49 rex.WB Code starting with the faulting instruction =========================================== 0:49 8b 17 mov(%r15),%rdx 3:49 89 11 mov%rdx,(%r9) 6:41 8b 57 28mov0x28(%r15),%edx a:45 8b 5f 34mov0x34(%r15),%r11d e:49 c7 07 00 00 00 00 movq $0x0,(%r15) 15:49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS:000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS:0010 DS: 0000 ES: 0000 C ---truncated--- Solution(s) oracle-linux-upgrade-kernel oracle-linux-upgrade-kernel-uek References https://attackerkb.com/topics/cve-2024-49949 CVE - 2024-49949 ELSA-2024-10939 ELSA-2024-10943 ELSA-2024-12884
-
Amazon Linux AMI: CVE-2024-49936: Security patch for kernel (ALAS-2025-1957)
Amazon Linux AMI: CVE-2024-49936: Security patch for kernel (ALAS-2025-1957) Severity 4 CVSS (AV:L/AC:M/Au:N/C:P/I:P/A:P) Published 10/21/2024 Created 02/11/2025 Added 02/06/2025 Modified 02/06/2025 Description In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe. Solution(s) amazon-linux-upgrade-kernel References ALAS-2025-1957 CVE-2024-49936
-
Ubuntu: (CVE-2022-48948): linux vulnerability
Ubuntu: (CVE-2022-48948): linux vulnerability Severity 7 CVSS (AV:L/AC:L/Au:S/C:C/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: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. 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-48948 CVE - 2022-48948 https://git.kernel.org/linus/4c92670b16727365699fe4b19ed32013bab2c107 https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5 https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35 https://git.kernel.org/stable/c/4c92670b16727365699fe4b19ed32013bab2c107 https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5 https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506cce1954 https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24 https://git.kernel.org/stable/c/d1a92bb8d697f170d93fe922da763d7d156b8841 https://www.cve.org/CVERecord?id=CVE-2022-48948 View more
-
Ubuntu: (CVE-2022-48982): linux vulnerability
Ubuntu: (CVE-2022-48982): 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: Bluetooth: Fix crash when replugging CSR fake controllers It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic: [ 71.986122] Call Trace: [ 71.986124]<TASK> [ 71.986125]blocking_notifier_chain_register+0x33/0x60 [ 71.986130]hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154]btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159]? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162]? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167]usb_probe_interface+0xe3/0x2b0 [ 71.986171]really_probe+0xdb/0x380 [ 71.986174]? pm_runtime_barrier+0x54/0x90 [ 71.986177]__driver_probe_device+0x78/0x170 [ 71.986180]driver_probe_device+0x1f/0x90 [ 71.986183]__device_attach_driver+0x89/0x110 [ 71.986186]? driver_allows_async_probing+0x70/0x70 [ 71.986189]bus_for_each_drv+0x8c/0xe0 [ 71.986192]__device_attach+0xb2/0x1e0 [ 71.986195]bus_probe_device+0x92/0xb0 [ 71.986198]device_add+0x422/0x9a0 [ 71.986201]? sysfs_merge_group+0xd4/0x110 [ 71.986205]usb_set_configuration+0x57a/0x820 [ 71.986208]usb_generic_driver_probe+0x4f/0x70 [ 71.986211]usb_probe_device+0x3a/0x110 [ 71.986213]really_probe+0xdb/0x380 [ 71.986216]? pm_runtime_barrier+0x54/0x90 [ 71.986219]__driver_probe_device+0x78/0x170 [ 71.986221]driver_probe_device+0x1f/0x90 [ 71.986224]__device_attach_driver+0x89/0x110 [ 71.986227]? driver_allows_async_probing+0x70/0x70 [ 71.986230]bus_for_each_drv+0x8c/0xe0 [ 71.986232]__device_attach+0xb2/0x1e0 [ 71.986235]bus_probe_device+0x92/0xb0 [ 71.986237]device_add+0x422/0x9a0 [ 71.986239]? _dev_info+0x7d/0x98 [ 71.986242]? blake2s_update+0x4c/0xc0 [ 71.986246]usb_new_device.cold+0x148/0x36d [ 71.986250]hub_event+0xa8a/0x1910 [ 71.986255]process_one_work+0x1c4/0x380 [ 71.986259]worker_thread+0x51/0x390 [ 71.986262]? rescuer_thread+0x3b0/0x3b0 [ 71.986264]kthread+0xdb/0x110 [ 71.986266]? kthread_complete_and_exit+0x20/0x20 [ 71.986268]ret_from_fork+0x1f/0x30 [ 71.986273]</TASK> [ 71.986274] ---[ end trace 0000000000000000 ]--- [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17 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-48982 CVE - 2022-48982 https://git.kernel.org/linus/b5ca338751ad4783ec8d37b5d99c3e37b7813e59 https://git.kernel.org/stable/c/549b46f8130effccf168293270bb3b1d5da529cc https://git.kernel.org/stable/c/a49894a5ac3656f1a4f0f6b110460060e8026bf8 https://git.kernel.org/stable/c/b5ca338751ad4783ec8d37b5d99c3e37b7813e59 https://git.kernel.org/stable/c/dc8fa6570deadb70c3fb74d7cd8ce38849feaed0 https://www.cve.org/CVERecord?id=CVE-2022-48982 View more
-
Ubuntu: (CVE-2022-48978): linux vulnerability
Ubuntu: (CVE-2022-48978): 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: HID: core: fix shift-out-of-bounds in hid_report_raw_event Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32. 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-48978 CVE - 2022-48978 https://git.kernel.org/linus/ec61b41918587be530398b0d1c9a0d16619397e5 https://git.kernel.org/stable/c/151493fe5a6ed1a88decc929a7368a3f2a246914 https://git.kernel.org/stable/c/2b3b4d7aadaa1b6b58d0f34823bf86cfe8a31b4d https://git.kernel.org/stable/c/809783f8b4b600c7fb3bccb10fefef822601ea3b https://git.kernel.org/stable/c/8e14f20e12224ee2429f75a5c9418a700e26a8d3 https://git.kernel.org/stable/c/bc03f809da78fc79e4aee132d4e5c6a2b3aeec73 https://git.kernel.org/stable/c/db1ed1b3fb4ec0d19080a102956255769bc45c79 https://git.kernel.org/stable/c/ec61b41918587be530398b0d1c9a0d16619397e5 https://git.kernel.org/stable/c/f755d11c55b29049b77da5cd9ab2faae96eb33c3 https://www.cve.org/CVERecord?id=CVE-2022-48978 View more
-
Ubuntu: (CVE-2022-48972): linux vulnerability
Ubuntu: (CVE-2022-48972): 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: mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() Kernel fault injection test reports null-ptr-deref as follows: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace: <TASK> raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154_if_add() allocates wpan_dev as netdev's private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref. Use INIT_LIST_HEAD() on it to initialize it correctly. 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-48972 CVE - 2022-48972 https://git.kernel.org/linus/b3d72d3135d2ef68296c1ee174436efd65386f04 https://git.kernel.org/stable/c/1831d4540406708e48239cf38fd9c3b7ea98e08f https://git.kernel.org/stable/c/42c319635c0cf7eb36eccac6cda76532f47b61a3 https://git.kernel.org/stable/c/623918f40fa68e3bb21312a3fafb90f491bf5358 https://git.kernel.org/stable/c/7410f4d1221bb182510b7778ab6eefa8b9b7102d https://git.kernel.org/stable/c/9980a3ea20de40c83817877106c909cb032692d2 https://git.kernel.org/stable/c/a110287ef4a423980309490df632e1c1e73b3dc9 https://git.kernel.org/stable/c/b3d72d3135d2ef68296c1ee174436efd65386f04 https://git.kernel.org/stable/c/f00c84fb1635c27ba24ec5df65d5bd7d7dc00008 https://www.cve.org/CVERecord?id=CVE-2022-48972 View more