Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs, fscache: Prevent Oops in fscache_put_cache()<br /> <br /> This function dereferences "cache" and then checks if it&amp;#39;s<br /> IS_ERR_OR_NULL(). Check first, then dereference.

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 /> tcp: make sure init the accept_queue&amp;#39;s spinlocks once<br /> <br /> When I run syz&amp;#39;s reproduction C program locally, it causes the following<br /> issue:<br /> pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!<br /> WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)<br /> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)<br /> Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7<br /> 30 20 ce 8f e8 ad 56 42 ff 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90<br /> RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908<br /> RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900<br /> RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff<br /> R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000<br /> R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000<br /> FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> _raw_spin_unlock (kernel/locking/spinlock.c:186)<br /> inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)<br /> inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)<br /> tcp_check_req (net/ipv4/tcp_minisocks.c:868)<br /> tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)<br /> ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)<br /> ip_local_deliver_finish (net/ipv4/ip_input.c:234)<br /> __netif_receive_skb_one_core (net/core/dev.c:5529)<br /> process_backlog (./include/linux/rcupdate.h:779)<br /> __napi_poll (net/core/dev.c:6533)<br /> net_rx_action (net/core/dev.c:6604)<br /> __do_softirq (./arch/x86/include/asm/jump_label.h:27)<br /> do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)<br /> <br /> <br /> __local_bh_enable_ip (kernel/softirq.c:381)<br /> __dev_queue_xmit (net/core/dev.c:4374)<br /> ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)<br /> __ip_queue_xmit (net/ipv4/ip_output.c:535)<br /> __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)<br /> tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)<br /> tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)<br /> tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)<br /> __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)<br /> release_sock (net/core/sock.c:3536)<br /> inet_wait_for_connect (net/ipv4/af_inet.c:609)<br /> __inet_stream_connect (net/ipv4/af_inet.c:702)<br /> inet_stream_connect (net/ipv4/af_inet.c:748)<br /> __sys_connect (./include/linux/file.h:45 net/socket.c:2064)<br /> __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)<br /> do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)<br /> RIP: 0033:0x7fa10ff05a3d<br /> Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89<br /> c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d<br /> RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003<br /> RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640<br /> R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20<br /> <br /> <br /> The issue triggering process is analyzed as follows:<br /> Thread A Thread B<br /> tcp_v4_rcv //receive ack TCP packet inet_shutdown<br /> tcp_check_req tcp_disconnect //disconnect sock<br /> ... tcp_set_state(sk, TCP_CLOSE)<br /> inet_csk_complete_hashdance ...<br /> inet_csk_reqsk_queue_add <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix illegal rmb_desc access in SMC-D connection dump<br /> <br /> A crash was found when dumping SMC-D connections. It can be reproduced<br /> by following steps:<br /> <br /> - run nginx/wrk test:<br /> smc_run nginx<br /> smc_run wrk -t 16 -c 1000 -d -H &amp;#39;Connection: Close&amp;#39; <br /> <br /> - continuously dump SMC-D connections in parallel:<br /> watch -n 1 &amp;#39;smcss -D&amp;#39;<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000030<br /> CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55<br /> RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]<br /> Call Trace:<br /> <br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x66/0x150<br /> ? exc_page_fault+0x69/0x140<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]<br /> ? __kmalloc_node_track_caller+0x35d/0x430<br /> ? __alloc_skb+0x77/0x170<br /> smc_diag_dump_proto+0xd0/0xf0 [smc_diag]<br /> smc_diag_dump+0x26/0x60 [smc_diag]<br /> netlink_dump+0x19f/0x320<br /> __netlink_dump_start+0x1dc/0x300<br /> smc_diag_handler_dump+0x6a/0x80 [smc_diag]<br /> ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]<br /> sock_diag_rcv_msg+0x121/0x140<br /> ? __pfx_sock_diag_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x5a/0x110<br /> sock_diag_rcv+0x28/0x40<br /> netlink_unicast+0x22a/0x330<br /> netlink_sendmsg+0x1f8/0x420<br /> __sock_sendmsg+0xb0/0xc0<br /> ____sys_sendmsg+0x24e/0x300<br /> ? copy_msghdr_from_user+0x62/0x80<br /> ___sys_sendmsg+0x7c/0xd0<br /> ? __do_fault+0x34/0x160<br /> ? do_read_fault+0x5f/0x100<br /> ? do_fault+0xb0/0x110<br /> ? __handle_mm_fault+0x2b0/0x6c0<br /> __sys_sendmsg+0x4d/0x80<br /> do_syscall_64+0x69/0x180<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> It is possible that the connection is in process of being established<br /> when we dump it. Assumed that the connection has been registered in a<br /> link group by smc_conn_create() but the rmb_desc has not yet been<br /> initialized by smc_buf_create(), thus causing the illegal access to<br /> conn-&gt;rmb_desc. So fix it by checking before dump.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: scrub: avoid use-after-free when chunk length is not 64K aligned<br /> <br /> [BUG]<br /> There is a bug report that, on a ext4-converted btrfs, scrub leads to<br /> various problems, including:<br /> <br /> - "unable to find chunk map" errors<br /> BTRFS info (device vdb): scrub: started on devid 1<br /> BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 4096<br /> BTRFS critical (device vdb): unable to find chunk map for logical 2214744064 length 45056<br /> <br /> This would lead to unrepariable errors.<br /> <br /> - Use-after-free KASAN reports:<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in __blk_rq_map_sg+0x18f/0x7c0<br /> Read of size 8 at addr ffff8881013c9040 by task btrfs/909<br /> CPU: 0 PID: 909 Comm: btrfs Not tainted 6.7.0-x64v3-dbg #11 c50636e9419a8354555555245df535e380563b2b<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 2023.11-2 12/24/2023<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x43/0x60<br /> print_report+0xcf/0x640<br /> kasan_report+0xa6/0xd0<br /> __blk_rq_map_sg+0x18f/0x7c0<br /> virtblk_prep_rq.isra.0+0x215/0x6a0 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]<br /> virtio_queue_rqs+0xc4/0x310 [virtio_blk 19a65eeee9ae6fcf02edfad39bb9ddee07dcdaff]<br /> blk_mq_flush_plug_list.part.0+0x780/0x860<br /> __blk_flush_plug+0x1ba/0x220<br /> blk_finish_plug+0x3b/0x60<br /> submit_initial_group_read+0x10a/0x290 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> flush_scrub_stripes+0x38e/0x430 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> scrub_stripe+0x82a/0xae0 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> scrub_chunk+0x178/0x200 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> scrub_enumerate_chunks+0x4bc/0xa30 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> btrfs_scrub_dev+0x398/0x810 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> btrfs_ioctl+0x4b9/0x3020 [btrfs e57987a360bed82fe8756dcd3e0de5406ccfe965]<br /> __x64_sys_ioctl+0xbd/0x100<br /> do_syscall_64+0x5d/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> RIP: 0033:0x7f47e5e0952b<br /> <br /> - Crash, mostly due to above use-after-free<br /> <br /> [CAUSE]<br /> The converted fs has the following data chunk layout:<br /> <br /> item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 2214658048) itemoff 16025 itemsize 80<br /> length 86016 owner 2 stripe_len 65536 type DATA|single<br /> <br /> For above logical bytenr 2214744064, it&amp;#39;s at the chunk end<br /> (2214658048 + 86016 = 2214744064).<br /> <br /> This means btrfs_submit_bio() would split the bio, and trigger endio<br /> function for both of the two halves.<br /> <br /> However scrub_submit_initial_read() would only expect the endio function<br /> to be called once, not any more.<br /> This means the first endio function would already free the bbio::bio,<br /> leaving the bvec freed, thus the 2nd endio call would lead to<br /> use-after-free.<br /> <br /> [FIX]<br /> - Make sure scrub_read_endio() only updates bits in its range<br /> Since we may read less than 64K at the end of the chunk, we should not<br /> touch the bits beyond chunk boundary.<br /> <br /> - Make sure scrub_submit_initial_read() only to read the chunk range<br /> This is done by calculating the real number of sectors we need to<br /> read, and add sector-by-sector to the bio.<br /> <br /> Thankfully the scrub read repair path won&amp;#39;t need extra fixes:<br /> <br /> - scrub_stripe_submit_repair_read()<br /> With above fixes, we won&amp;#39;t update error bit for range beyond chunk,<br /> thus scrub_stripe_submit_repair_read() should never submit any read<br /> beyond the chunk.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/proc/task_mmu: move mmu notification mechanism inside mm lock<br /> <br /> Move mmu notification mechanism inside mm lock to prevent race condition<br /> in other components which depend on it. The notifier will invalidate<br /> memory range. Depending upon the number of iterations, different memory<br /> ranges would be invalidated.<br /> <br /> The following warning would be removed by this patch:<br /> WARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734<br /> <br /> There is no behavioural and performance change with this patch when<br /> there is no component registered with the mmu notifier.<br /> <br /> [akpm@linux-foundation.org: narrow the scope of `range&amp;#39;, per Sean]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: Fix module loading free order<br /> <br /> Reverse order of kfree calls to resolve use-after-free error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio-ap: always filter entire AP matrix<br /> <br /> The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or<br /> domain is assigned to the mdev. The purpose of the function is to update<br /> the guest&amp;#39;s AP configuration by filtering the matrix of adapters and<br /> domains assigned to the mdev. When an adapter or domain is assigned, only<br /> the APQNs associated with the APID of the new adapter or APQI of the new<br /> domain are inspected. If an APQN does not reference a queue device bound to<br /> the vfio_ap device driver, then it&amp;#39;s APID will be filtered from the mdev&amp;#39;s<br /> matrix when updating the guest&amp;#39;s AP configuration.<br /> <br /> Inspecting only the APID of the new adapter or APQI of the new domain will<br /> result in passing AP queues through to a guest that are not bound to the<br /> vfio_ap device driver under certain circumstances. Consider the following:<br /> <br /> guest&amp;#39;s AP configuration (all also assigned to the mdev&amp;#39;s matrix):<br /> 14.0004<br /> 14.0005<br /> 14.0006<br /> 16.0004<br /> 16.0005<br /> 16.0006<br /> <br /> unassign domain 4<br /> unbind queue 16.0005<br /> assign domain 4<br /> <br /> When domain 4 is re-assigned, since only domain 4 will be inspected, the<br /> APQNs that will be examined will be:<br /> 14.0004<br /> 16.0004<br /> <br /> Since both of those APQNs reference queue devices that are bound to the<br /> vfio_ap device driver, nothing will get filtered from the mdev&amp;#39;s matrix<br /> when updating the guest&amp;#39;s AP configuration. Consequently, queue 16.0005<br /> will get passed through despite not being bound to the driver. This<br /> violates the linux device model requirement that a guest shall only be<br /> given access to devices bound to the device driver facilitating their<br /> pass-through.<br /> <br /> To resolve this problem, every adapter and domain assigned to the mdev will<br /> be inspected when filtering the mdev&amp;#39;s matrix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/sme: Always exit sme_alloc() early with existing storage<br /> <br /> When sme_alloc() is called with existing storage and we are not flushing we<br /> will always allocate new storage, both leaking the existing storage and<br /> corrupting the state. Fix this by separating the checks for flushing and<br /> for existing storage as we do for SVE.<br /> <br /> Callers that reallocate (eg, due to changing the vector length) should<br /> call sme_free() themselves.

The User Registration WordPress plugin before 2.12 does not prevent users with at least the contributor role from rendering sensitive shortcodes, allowing them to generate, and leak, valid password reset URLs, which they can use to take over any accounts.

The Photos and Files Contest Gallery WordPress plugin before 21.3.1 does not sanitize and escape some parameters, which could allow users with a role as low as author to perform Cross-Site Scripting attacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix global oob in ksmbd_nl_policy<br /> <br /> Similar to a reported issue (check the commit b33fb5b801c6 ("net:<br /> qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds<br /> another global out-of-bounds read for policy ksmbd_nl_policy. See bug<br /> trace below:<br /> <br /> ==================================================================<br /> BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]<br /> BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600<br /> Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810<br /> <br /> CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x172/0x475 mm/kasan/report.c:395<br /> kasan_report+0xbb/0x1c0 mm/kasan/report.c:495<br /> validate_nla lib/nlattr.c:386 [inline]<br /> __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600<br /> __nla_parse+0x3e/0x50 lib/nlattr.c:697<br /> __nlmsg_parse include/net/netlink.h:748 [inline]<br /> genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565<br /> genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734<br /> genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]<br /> genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850<br /> netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540<br /> genl_rcv+0x24/0x40 net/netlink/genetlink.c:861<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0x154/0x190 net/socket.c:734<br /> ____sys_sendmsg+0x6df/0x840 net/socket.c:2482<br /> ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536<br /> __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fdd66a8f359<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359<br /> RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003<br /> RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000<br /> <br /> <br /> The buggy address belongs to the variable:<br /> ksmbd_nl_policy+0x100/0xa80<br /> <br /> The buggy address belongs to the physical page:<br /> page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b<br /> flags: 0x200000000001000(reserved|node=0|zone=2)<br /> raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9<br /> ^<br /> ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05<br /> ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9<br /> ==================================================================<br /> <br /> To fix it, add a placeholder named __KSMBD_EVENT_MAX and let<br /> KSMBD_EVENT_MAX to be its original value - 1 according to what other<br /> netlink families do. Also change two sites that refer the<br /> KSMBD_EVENT_MAX to correct value.