Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd: Check event before enable to avoid GPF<br /> <br /> On AMD machines cpuc-&gt;events[idx] can become NULL in a subtle race<br /> condition with NMI-&gt;throttle-&gt;x86_pmu_stop().<br /> <br /> Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.<br /> This appears to be an AMD only issue.<br /> <br /> Syzkaller reported a GPF in amd_pmu_enable_all.<br /> <br /> INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143<br /> msecs<br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]<br /> CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk<br /> RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195<br /> arch/x86/events/core.c:1430)<br /> RSP: 0018:ffff888118009d60 EFLAGS: 00010012<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002<br /> R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601<br /> FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))<br /> x86_pmu_enable (arch/x86/events/core.c:1360)<br /> event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186<br /> kernel/events/core.c:2346)<br /> __perf_remove_from_context (kernel/events/core.c:2435)<br /> event_function (kernel/events/core.c:259)<br /> remote_function (kernel/events/core.c:92 (discriminator 1)<br /> kernel/events/core.c:72 (discriminator 1))<br /> __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27<br /> ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64<br /> kernel/smp.c:135 kernel/smp.c:540)<br /> __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27<br /> ./include/linux/jump_label.h:207<br /> ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)<br /> sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)<br /> arch/x86/kernel/smp.c:266 (discriminator 47))<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> caif: fix integer underflow in cffrml_receive()<br /> <br /> The cffrml_receive() function extracts a length field from the packet<br /> header and, when FCS is disabled, subtracts 2 from this length without<br /> validating that len &gt;= 2.<br /> <br /> If an attacker sends a malicious packet with a length field of 0 or 1<br /> to an interface with FCS disabled, the subtraction causes an integer<br /> underflow.<br /> <br /> This can lead to memory exhaustion and kernel instability, potential<br /> information disclosure if padding contains uninitialized kernel memory.<br /> <br /> Fix this by validating that len &gt;= 2 before performing the subtraction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix double unregister of HCA_PORTS component<br /> <br /> Clear hca_devcom_comp in device&amp;#39;s private data after unregistering it in<br /> LAG teardown. Otherwise a slightly lagging second pass through<br /> mlx5_unload_one() might try to unregister it again and trip over<br /> use-after-free.<br /> <br /> On s390 almost all PCI level recovery events trigger two passes through<br /> mxl5_unload_one() - one through the poll_health() method and one through<br /> mlx5_pci_err_detected() as callback from generic PCI error recovery.<br /> While testing PCI error recovery paths with more kernel debug features<br /> enabled, this issue reproducibly led to kernel panics with the following<br /> call chain:<br /> <br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803 ESOP-2 FSI<br /> Fault in home space mode while using kernel ASCE.<br /> AS:00000000705c4007 R3:0000000000000024<br /> Oops: 0038 ilc:3 [#1]SMP<br /> <br /> CPU: 14 UID: 0 PID: 156 Comm: kmcheck Kdump: loaded Not tainted<br /> 6.18.0-20251130.rc7.git0.16131a59cab1.300.fc43.s390x+debug #1 PREEMPT<br /> <br /> Krnl PSW : 0404e00180000000 0000020fc86aa1dc (__lock_acquire+0x5c/0x15f0)<br /> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3<br /> Krnl GPRS: 0000000000000000 0000020f00000001 6b6b6b6b6b6b6c33 0000000000000000<br /> 0000000000000000 0000000000000000 0000000000000001 0000000000000000<br /> 0000000000000000 0000020fca28b820 0000000000000000 0000010a1ced8100<br /> 0000010a1ced8100 0000020fc9775068 0000018fce14f8b8 0000018fce14f7f8<br /> Krnl Code: 0000020fc86aa1cc: e3b003400004 lg %r11,832<br /> 0000020fc86aa1d2: a7840211 brc 8,0000020fc86aa5f4<br /> *0000020fc86aa1d6: c09000df0b25 larl %r9,0000020fca28b820<br /> &gt;0000020fc86aa1dc: d50790002000 clc 0(8,%r9),0(%r2)<br /> 0000020fc86aa1e2: a7840209 brc 8,0000020fc86aa5f4<br /> 0000020fc86aa1e6: c0e001100401 larl %r14,0000020fca8aa9e8<br /> 0000020fc86aa1ec: c01000e25a00 larl %r1,0000020fca2f55ec<br /> 0000020fc86aa1f2: a7eb00e8 aghi %r14,232<br /> <br /> Call Trace:<br /> __lock_acquire+0x5c/0x15f0<br /> lock_acquire.part.0+0xf8/0x270<br /> lock_acquire+0xb0/0x1b0<br /> down_write+0x5a/0x250<br /> mlx5_detach_device+0x42/0x110 [mlx5_core]<br /> mlx5_unload_one_devl_locked+0x50/0xc0 [mlx5_core]<br /> mlx5_unload_one+0x42/0x60 [mlx5_core]<br /> mlx5_pci_err_detected+0x94/0x150 [mlx5_core]<br /> zpci_event_attempt_error_recovery+0xcc/0x388

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: missing copy_finish in fuse-over-io-uring argument copies<br /> <br /> Fix a possible reference count leak of payload pages during<br /> fuse argument copies.<br /> <br /> [Joanne: simplified error cleanup]

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 /> ALSA: usb-mixer: us16x08: validate meter packet indices<br /> <br /> get_meter_levels_from_urb() parses the 64-byte meter packets sent by<br /> the device and fills the per-channel arrays meter_level[],<br /> comp_level[] and master_level[] in struct snd_us16x08_meter_store.<br /> <br /> Currently the function derives the channel index directly from the<br /> meter packet (MUB2(meter_urb, s) - 1) and uses it to index those<br /> arrays without validating the range. If the packet contains a<br /> negative or out-of-range channel number, the driver may write past<br /> the end of these arrays.<br /> <br /> Introduce a local channel variable and validate it before updating the<br /> arrays. We reject negative indices, limit meter_level[] and<br /> comp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]<br /> updates with ARRAY_SIZE(master_level).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix a UAF problem in xattr repair<br /> <br /> The xchk_setup_xattr_buf function can allocate a new value buffer, which<br /> means that any reference to ab-&gt;value before the call could become a<br /> dangling pointer. Fix this by moving an assignment to after the buffer<br /> setup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix middle attribute validation in push_nsh() action<br /> <br /> The push_nsh() action structure looks like this:<br /> <br /> OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))<br /> <br /> The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK&amp;#39;ed by the<br /> nla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost<br /> OVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK&amp;#39;ed by the nla_for_each_nested()<br /> inside nsh_key_put_from_nlattr(). But nothing checks if the attribute<br /> in the middle is OK. We don&amp;#39;t even check that this attribute is the<br /> OVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()<br /> calls - first time directly while calling validate_push_nsh() and the<br /> second time as part of the nla_for_each_nested() macro, which isn&amp;#39;t<br /> safe, potentially causing invalid memory access if the size of this<br /> attribute is incorrect. The failure may not be noticed during<br /> validation due to larger netlink buffer, but cause trouble later during<br /> action execution where the buffer is allocated exactly to the size:<br /> <br /> BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]<br /> Read of size 184 at addr ffff88816459a634 by task a.out/22624<br /> <br /> CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x70<br /> print_address_description.constprop.0+0x2c/0x390<br /> kasan_report+0xdd/0x110<br /> kasan_check_range+0x35/0x1b0<br /> __asan_memcpy+0x20/0x60<br /> nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]<br /> push_nsh+0x82/0x120 [openvswitch]<br /> do_execute_actions+0x1405/0x2840 [openvswitch]<br /> ovs_execute_actions+0xd5/0x3b0 [openvswitch]<br /> ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch]<br /> genl_family_rcv_msg_doit+0x1d6/0x2b0<br /> genl_family_rcv_msg+0x336/0x580<br /> genl_rcv_msg+0x9f/0x130<br /> netlink_rcv_skb+0x11f/0x370<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x73e/0xaa0<br /> netlink_sendmsg+0x744/0xbf0<br /> __sys_sendto+0x3d6/0x450<br /> do_syscall_64+0x79/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> <br /> Let&amp;#39;s add some checks that the attribute is properly sized and it&amp;#39;s<br /> the only one attribute inside the action. Technically, there is no<br /> real reason for OVS_KEY_ATTR_NSH to be there, as we know that we&amp;#39;re<br /> pushing an NSH header already, it just creates extra nesting, but<br /> that&amp;#39;s how uAPI works today. So, keeping as it is.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: skip lock-range check on equal size to avoid size==0 underflow<br /> <br /> When size equals the current i_size (including 0), the code used to call<br /> check_lock_range(filp, i_size, size - 1, WRITE), which computes `size - 1`<br /> and can underflow for size==0. Skip the equal case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: Fix memory leak in nr_sendmsg()<br /> <br /> syzbot reported a memory leak [1].<br /> <br /> When function sock_alloc_send_skb() return NULL in nr_output(), the<br /> original skb is not freed, which was allocated in nr_sendmsg(). Fix this<br /> by freeing it before return.<br /> <br /> [1]<br /> BUG: memory leak<br /> unreferenced object 0xffff888129f35500 (size 240):<br /> comm "syz.0.17", pid 6119, jiffies 4294944652<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(....<br /> backtrace (crc 1456a3e4):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]<br /> slab_post_alloc_hook mm/slub.c:4983 [inline]<br /> slab_alloc_node mm/slub.c:5288 [inline]<br /> kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340<br /> __alloc_skb+0x203/0x240 net/core/skbuff.c:660<br /> alloc_skb include/linux/skbuff.h:1383 [inline]<br /> alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671<br /> sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965<br /> sock_alloc_send_skb include/net/sock.h:1859 [inline]<br /> nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> sock_write_iter+0x293/0x2a0 net/socket.c:1195<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0x45d/0x710 fs/read_write.c:686<br /> ksys_write+0x143/0x170 fs/read_write.c:738<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsnotify: do not generate ACCESS/MODIFY events on child for special files<br /> <br /> inotify/fanotify do not allow users with no read access to a file to<br /> subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the<br /> same user to subscribe for watching events on children when the user<br /> has access to the parent directory (e.g. /dev).<br /> <br /> Users with no read access to a file but with read access to its parent<br /> directory can still stat the file and see if it was accessed/modified<br /> via atime/mtime change.<br /> <br /> The same is not true for special files (e.g. /dev/null). Users will not<br /> generally observe atime/mtime changes when other users read/write to<br /> special files, only when someone sets atime/mtime via utimensat().<br /> <br /> Align fsnotify events with this stat behavior and do not generate<br /> ACCESS/MODIFY events to parent watchers on read/write of special files.<br /> The events are still generated to parent watchers on utimensat(). This<br /> closes some side-channels that could be possibly used for information<br /> exfiltration [1].<br /> <br /> [1] https://snee.la/pdf/pubs/file-notification-attacks.pdf

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: duplicate handshake cancellations leak socket<br /> <br /> When a handshake request is cancelled it is removed from the<br /> handshake_net-&gt;hn_requests list, but it is still present in the<br /> handshake_rhashtbl until it is destroyed.<br /> <br /> If a second cancellation request arrives for the same handshake request,<br /> then remove_pending() will return false... and assuming<br /> HANDSHAKE_F_REQ_COMPLETED isn&amp;#39;t set in req-&gt;hr_flags, we&amp;#39;ll continue<br /> processing through the out_true label, where we put another reference on<br /> the sock and a refcount underflow occurs.<br /> <br /> This can happen for example if a handshake times out - particularly if<br /> the SUNRPC client sends the AUTH_TLS probe to the server but doesn&amp;#39;t<br /> follow it up with the ClientHello due to a problem with tlshd. When the<br /> timeout is hit on the server, the server will send a FIN, which triggers<br /> a cancellation request via xs_reset_transport(). When the timeout is<br /> hit on the client, another cancellation request happens via<br /> xs_tls_handshake_sync().<br /> <br /> Add a test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED) in the pending cancel<br /> path so duplicate cancels can be detected.