Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: disallow setting special AP channel widths<br /> <br /> Setting the AP channel width is meant for use with the normal<br /> 20/40/... MHz channel width progression, and switching around<br /> in S1G or narrow channels isn&amp;#39;t supported. Disallow that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: avoid BUG_ON() while continue reshape after reassembling<br /> <br /> Currently, mdadm support --revert-reshape to abort the reshape while<br /> reassembling, as the test 07revert-grow. However, following BUG_ON()<br /> can be triggerred by the test:<br /> <br /> kernel BUG at drivers/md/raid5.c:6278!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> irq event stamp: 158985<br /> CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94<br /> RIP: 0010:reshape_request+0x3f1/0xe60<br /> Call Trace:<br /> <br /> raid5_sync_request+0x43d/0x550<br /> md_do_sync+0xb7a/0x2110<br /> md_thread+0x294/0x2b0<br /> kthread+0x147/0x1c0<br /> ret_from_fork+0x59/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Root cause is that --revert-reshape update the raid_disks from 5 to 4,<br /> while reshape position is still set, and after reassembling the array,<br /> reshape position will be read from super block, then during reshape the<br /> checking of &amp;#39;writepos&amp;#39; that is caculated by old reshape position will<br /> fail.<br /> <br /> Fix this panic the easy way first, by converting the BUG_ON() to<br /> WARN_ON(), and stop the reshape if checkings fail.<br /> <br /> Noted that mdadm must fix --revert-shape as well, and probably md/raid<br /> should enhance metadata validation as well, however this means<br /> reassemble will fail and there must be user tools to fix the wrong<br /> metadata.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: prevent potential speculation leaks in gpio_device_get_desc()<br /> <br /> Userspace may trigger a speculative read of an address outside the gpio<br /> descriptor array.<br /> Users can do that by calling gpio_ioctl() with an offset out of range.<br /> Offset is copied from user and then used as an array index to get<br /> the gpio descriptor without sanitization in gpio_device_get_desc().<br /> <br /> This change ensures that the offset is sanitized by using<br /> array_index_nospec() to mitigate any possibility of speculative<br /> information leaks.<br /> <br /> This bug was discovered and resolved using Coverity Static Analysis<br /> Security Testing (SAST) by Synopsys, Inc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bridge: mcast: wait for previous gc cycles when removing port<br /> <br /> syzbot hit a use-after-free[1] which is caused because the bridge doesn&amp;#39;t<br /> make sure that all previous garbage has been collected when removing a<br /> port. What happens is:<br /> CPU 1 CPU 2<br /> start gc cycle remove port<br /> acquire gc lock first<br /> wait for lock<br /> call br_multicasg_gc() directly<br /> acquire lock now but free port<br /> the port can be freed<br /> while grp timers still<br /> running<br /> <br /> Make sure all previous gc cycles have finished by using flush_work before<br /> freeing the port.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861<br /> Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699<br /> <br /> CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc3/0x620 mm/kasan/report.c:488<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861<br /> call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792<br /> expire_timers kernel/time/timer.c:1843 [inline]<br /> __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417<br /> __run_timer_base kernel/time/timer.c:2428 [inline]<br /> __run_timer_base kernel/time/timer.c:2421 [inline]<br /> run_timer_base+0x111/0x190 kernel/time/timer.c:2437

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: Fix null-ptr-deref in reuseport_add_sock().<br /> <br /> syzbot reported a null-ptr-deref while accessing sk2-&gt;sk_reuseport_cb in<br /> reuseport_add_sock(). [0]<br /> <br /> The repro first creates a listener with SO_REUSEPORT. Then, it creates<br /> another listener on the same port and concurrently closes the first<br /> listener.<br /> <br /> The second listen() calls reuseport_add_sock() with the first listener as<br /> sk2, where sk2-&gt;sk_reuseport_cb is not expected to be cleared concurrently,<br /> but the close() does clear it by reuseport_detach_sock().<br /> <br /> The problem is SCTP does not properly synchronise reuseport_alloc(),<br /> reuseport_add_sock(), and reuseport_detach_sock().<br /> <br /> The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must<br /> provide synchronisation for sockets that are classified into the same<br /> reuseport group.<br /> <br /> Otherwise, such sockets form multiple identical reuseport groups, and<br /> all groups except one would be silently dead.<br /> <br /> 1. Two sockets call listen() concurrently<br /> 2. No socket in the same group found in sctp_ep_hashtable[]<br /> 3. Two sockets call reuseport_alloc() and form two reuseport groups<br /> 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives<br /> incoming packets<br /> <br /> Also, the reported null-ptr-deref could occur.<br /> <br /> TCP/UDP guarantees that would not happen by holding the hash bucket lock.<br /> <br /> Let&amp;#39;s apply the locking strategy to __sctp_hash_endpoint() and<br /> __sctp_unhash_endpoint().<br /> <br /> [0]:<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024<br /> RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350<br /> Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14<br /> RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202<br /> RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012<br /> RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385<br /> R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0<br /> R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __sctp_hash_endpoint net/sctp/input.c:762 [inline]<br /> sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790<br /> sctp_listen_start net/sctp/socket.c:8570 [inline]<br /> sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625<br /> __sys_listen_socket net/socket.c:1883 [inline]<br /> __sys_listen+0x1b7/0x230 net/socket.c:1894<br /> __do_sys_listen net/socket.c:1902 [inline]<br /> __se_sys_listen net/socket.c:1900 [inline]<br /> __x64_sys_listen+0x5a/0x70 net/socket.c:1900<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f24e46039b9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032<br /> RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9<br /> RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004<br /> RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0<br /> R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c<br /> R13:<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Have format file honor EVENT_FILE_FL_FREED<br /> <br /> When eventfs was introduced, special care had to be done to coordinate the<br /> freeing of the file meta data with the files that are exposed to user<br /> space. The file meta data would have a ref count that is set when the file<br /> is created and would be decremented and freed after the last user that<br /> opened the file closed it. When the file meta data was to be freed, it<br /> would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed,<br /> and any new references made (like new opens or reads) would fail as it is<br /> marked freed. This allowed other meta data to be freed after this flag was<br /> set (under the event_mutex).<br /> <br /> All the files that were dynamically created in the events directory had a<br /> pointer to the file meta data and would call event_release() when the last<br /> reference to the user space file was closed. This would be the time that it<br /> is safe to free the file meta data.<br /> <br /> A shortcut was made for the "format" file. It&amp;#39;s i_private would point to<br /> the "call" entry directly and not point to the file&amp;#39;s meta data. This is<br /> because all format files are the same for the same "call", so it was<br /> thought there was no reason to differentiate them. The other files<br /> maintain state (like the "enable", "trigger", etc). But this meant if the<br /> file were to disappear, the "format" file would be unaware of it.<br /> <br /> This caused a race that could be trigger via the user_events test (that<br /> would create dynamic events and free them), and running a loop that would<br /> read the user_events format files:<br /> <br /> In one console run:<br /> <br /> # cd tools/testing/selftests/user_events<br /> # while true; do ./ftrace_test; done<br /> <br /> And in another console run:<br /> <br /> # cd /sys/kernel/tracing/<br /> # while true; do cat events/user_events/__test_event/format; done 2&gt;/dev/null<br /> <br /> With KASAN memory checking, it would trigger a use-after-free bug report<br /> (which was a real bug). This was because the format file was not checking<br /> the file&amp;#39;s meta data flag "EVENT_FILE_FL_FREED", so it would access the<br /> event that the file meta data pointed to after the event was freed.<br /> <br /> After inspection, there are other locations that were found to not check<br /> the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a<br /> new helper function: event_file_file() that will make sure that the<br /> event_mutex is held, and will return NULL if the trace_event_file has the<br /> EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file<br /> pointer use event_file_file() and check for NULL. Later uses can still use<br /> the event_file_data() helper function if the event_mutex is still held and<br /> was not released since the event_file_file() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: cs-amp-lib: Fix NULL pointer crash if efi.get_variable is NULL<br /> <br /> Call efi_rt_services_supported() to check that efi.get_variable exists<br /> before calling it.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401<br /> <br /> When users run the command:<br /> <br /> cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log<br /> <br /> The following NULL pointer dereference happens:<br /> <br /> [ +0.000003] BUG: kernel NULL pointer dereference, address: NULL<br /> [ +0.000005] #PF: supervisor instruction fetch in kernel mode<br /> [ +0.000002] #PF: error_code(0x0010) - not-present page<br /> [ +0.000002] PGD 0 P4D 0<br /> [ +0.000004] Oops: 0010 [#1] PREEMPT SMP NOPTI<br /> [ +0.000003] RIP: 0010:0x0<br /> [ +0.000008] Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> [...]<br /> [ +0.000002] PKRU: 55555554<br /> [ +0.000002] Call Trace:<br /> [ +0.000002] <br /> [ +0.000003] ? show_regs+0x65/0x70<br /> [ +0.000006] ? __die+0x24/0x70<br /> [ +0.000004] ? page_fault_oops+0x160/0x470<br /> [ +0.000006] ? do_user_addr_fault+0x2b5/0x690<br /> [ +0.000003] ? prb_read_valid+0x1c/0x30<br /> [ +0.000005] ? exc_page_fault+0x8c/0x1a0<br /> [ +0.000005] ? asm_exc_page_fault+0x27/0x30<br /> [ +0.000012] dcn10_log_color_state+0xf9/0x510 [amdgpu]<br /> [ +0.000306] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ +0.000003] ? vsnprintf+0x2fb/0x600<br /> [ +0.000009] dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu]<br /> [ +0.000218] ? __mod_memcg_lruvec_state+0xe8/0x170<br /> [ +0.000008] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ +0.000002] ? debug_smp_processor_id+0x17/0x20<br /> [ +0.000003] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ +0.000002] ? set_ptes.isra.0+0x2b/0x90<br /> [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ +0.000002] ? _raw_spin_unlock+0x19/0x40<br /> [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ +0.000002] ? do_anonymous_page+0x337/0x700<br /> [ +0.000004] dtn_log_read+0x82/0x120 [amdgpu]<br /> [ +0.000207] full_proxy_read+0x66/0x90<br /> [ +0.000007] vfs_read+0xb0/0x340<br /> [ +0.000005] ? __count_memcg_events+0x79/0xe0<br /> [ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ +0.000003] ? count_memcg_events.constprop.0+0x1e/0x40<br /> [ +0.000003] ? handle_mm_fault+0xb2/0x370<br /> [ +0.000003] ksys_read+0x6b/0xf0<br /> [ +0.000004] __x64_sys_read+0x19/0x20<br /> [ +0.000003] do_syscall_64+0x60/0x130<br /> [ +0.000004] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ +0.000003] RIP: 0033:0x7fdf32f147e2<br /> [...]<br /> <br /> This error happens when the color log tries to read the gamut remap<br /> information from DCN401 which is not initialized in the dcn401_dpp_funcs<br /> which leads to a null pointer dereference. This commit addresses this<br /> issue by adding a proper guard to access the gamut_remap callback in<br /> case the specific ASIC did not implement this function.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/admgpu: fix dereferencing null pointer context<br /> <br /> When user space sets an invalid ta type, the pointer context will be empty.<br /> So it need to check the pointer context before using it

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix overflow in get_free_elt()<br /> <br /> "tracing_map-&gt;next_elt" in get_free_elt() is at risk of overflowing.<br /> <br /> Once it overflows, new elements can still be inserted into the tracing_map<br /> even though the maximum number of elements (`max_elts`) has been reached.<br /> Continuing to insert elements after the overflow could result in the<br /> tracing_map containing "tracing_map-&gt;max_size" elements, leaving no empty<br /> entries.<br /> If any attempt is made to insert an element into a full tracing_map using<br /> `__tracing_map_insert()`, it will cause an infinite loop with preemption<br /> disabled, leading to a CPU hang problem.<br /> <br /> Fix this by preventing any further increments to "tracing_map-&gt;next_elt"<br /> once it reaches "tracing_map-&gt;max_elt".