Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> raw: Fix NULL deref in raw_get_next().<br /> <br /> Dae R. Jeong reported a NULL deref in raw_get_next() [0].<br /> <br /> It seems that the repro was running these sequences in parallel so<br /> that one thread was iterating on a socket that was being freed in<br /> another netns.<br /> <br /> unshare(0x40060200)<br /> r0 = syz_open_procfs(0x0, &amp;(0x7f0000002080)=&amp;#39;net/raw\x00&amp;#39;)<br /> socket$inet_icmp_raw(0x2, 0x3, 0x1)<br /> pread64(r0, &amp;(0x7f0000000000)=""/10, 0xa, 0x10000000007f)<br /> <br /> After commit 0daf07e52709 ("raw: convert raw sockets to RCU"), we<br /> use RCU and hlist_nulls_for_each_entry() to iterate over SOCK_RAW<br /> sockets. However, we should use spinlock for slow paths to avoid<br /> the NULL deref.<br /> <br /> Also, SOCK_RAW does not use SLAB_TYPESAFE_BY_RCU, and the slab object<br /> is not reused during iteration in the grace period. In fact, the<br /> lockless readers do not check the nulls marker with get_nulls_value().<br /> So, SOCK_RAW should use hlist instead of hlist_nulls.<br /> <br /> Instead of adding an unnecessary barrier by sk_nulls_for_each_rcu(),<br /> let&amp;#39;s convert hlist_nulls to hlist and use sk_for_each_rcu() for<br /> fast paths and sk_for_each() and spinlock for /proc/net/raw.<br /> <br /> [0]:<br /> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> CPU: 2 PID: 20952 Comm: syz-executor.0 Not tainted 6.2.0-g048ec869bafd-dirty #7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:read_pnet include/net/net_namespace.h:383 [inline]<br /> RIP: 0010:sock_net include/net/sock.h:649 [inline]<br /> RIP: 0010:raw_get_next net/ipv4/raw.c:974 [inline]<br /> RIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline]<br /> RIP: 0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995<br /> Code: ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef<br /> RSP: 0018:ffffc9001154f9b0 EFLAGS: 00010206<br /> RAX: 0000000000000005 RBX: 1ffff1100302c8fd RCX: 0000000000000000<br /> RDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338<br /> RBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9<br /> R10: fffffbfff24b6bd9 R11: 0000000000000000 R12: ffff88801db73b78<br /> R13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030<br /> FS: 00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055bb9614b35f CR3: 000000003c672000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> seq_read_iter+0x4c6/0x10f0 fs/seq_file.c:225<br /> seq_read+0x224/0x320 fs/seq_file.c:162<br /> pde_read fs/proc/inode.c:316 [inline]<br /> proc_reg_read+0x23f/0x330 fs/proc/inode.c:328<br /> vfs_read+0x31e/0xd30 fs/read_write.c:468<br /> ksys_pread64 fs/read_write.c:665 [inline]<br /> __do_sys_pread64 fs/read_write.c:675 [inline]<br /> __se_sys_pread64 fs/read_write.c:672 [inline]<br /> __x64_sys_pread64+0x1e9/0x280 fs/read_write.c:672<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x478d29<br /> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 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 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f843ae8dbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000011<br /> RAX: ffffffffffffffda RBX: 0000000000791408 RCX: 0000000000478d29<br /> RDX: 000000000000000a RSI: 0000000020000000 RDI: 0000000000000003<br /> RBP: 00000000f477909a R08: 0000000000000000 R09: 0000000000000000<br /> R10: 000010000000007f R11: 0000000000000246 R12: 0000000000791740<br /> R13: 0000000000791414 R14: 0000000000791408 R15: 00007ffc2eb48a50<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010<br /> ---truncated---

A vulnerability was detected in Campcodes Online Job Finder System 1.0. The impacted element is an unknown function of the file /eris/applicationform.php. The manipulation of the argument picture results in unrestricted upload. It is possible to launch the attack remotely. The exploit is now public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix race on port output<br /> <br /> assume the following setup on a single machine:<br /> 1. An openvswitch instance with one bridge and default flows<br /> 2. two network namespaces "server" and "client"<br /> 3. two ovs interfaces "server" and "client" on the bridge<br /> 4. for each ovs interface a veth pair with a matching name and 32 rx and<br /> tx queues<br /> 5. move the ends of the veth pairs to the respective network namespaces<br /> 6. assign ip addresses to each of the veth ends in the namespaces (needs<br /> to be the same subnet)<br /> 7. start some http server on the server network namespace<br /> 8. test if a client in the client namespace can reach the http server<br /> <br /> when following the actions below the host has a chance of getting a cpu<br /> stuck in a infinite loop:<br /> 1. send a large amount of parallel requests to the http server (around<br /> 3000 curls should work)<br /> 2. in parallel delete the network namespace (do not delete interfaces or<br /> stop the server, just kill the namespace)<br /> <br /> there is a low chance that this will cause the below kernel cpu stuck<br /> message. If this does not happen just retry.<br /> Below there is also the output of bpftrace for the functions mentioned<br /> in the output.<br /> <br /> The series of events happening here is:<br /> 1. the network namespace is deleted calling<br /> `unregister_netdevice_many_notify` somewhere in the process<br /> 2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and<br /> then runs `synchronize_net`<br /> 3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`<br /> 4. this is then handled by `dp_device_event` which calls<br /> `ovs_netdev_detach_dev` (if a vport is found, which is the case for<br /> the veth interface attached to ovs)<br /> 5. this removes the rx_handlers of the device but does not prevent<br /> packages to be sent to the device<br /> 6. `dp_device_event` then queues the vport deletion to work in<br /> background as a ovs_lock is needed that we do not hold in the<br /> unregistration path<br /> 7. `unregister_netdevice_many_notify` continues to call<br /> `netdev_unregister_kobject` which sets `real_num_tx_queues` to 0<br /> 8. port deletion continues (but details are not relevant for this issue)<br /> 9. at some future point the background task deletes the vport<br /> <br /> If after 7. but before 9. a packet is send to the ovs vport (which is<br /> not deleted at this point in time) which forwards it to the<br /> `dev_queue_xmit` flow even though the device is unregistering.<br /> In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there is<br /> a while loop (if the packet has a rx_queue recorded) that is infinite if<br /> `dev-&gt;real_num_tx_queues` is zero.<br /> <br /> To prevent this from happening we update `do_output` to handle devices<br /> without carrier the same as if the device is not found (which would<br /> be the code path after 9. is done).<br /> <br /> Additionally we now produce a warning in `skb_tx_hash` if we will hit<br /> the infinite loop.<br /> <br /> bpftrace (first word is function name):<br /> <br /> __dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1<br /> netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1<br /> dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2<br /> ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2<br /> netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2<br /> synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024<br /> netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2<br /> dp_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6/addrconf: fix a potential refcount underflow for idev<br /> <br /> Now in addrconf_mod_rs_timer(), reference idev depends on whether<br /> rs_timer is not pending. Then modify rs_timer timeout.<br /> <br /> There is a time gap in [1], during which if the pending rs_timer<br /> becomes not pending. It will miss to hold idev, but the rs_timer<br /> is activated. Thus rs_timer callback function addrconf_rs_timer()<br /> will be executed and put idev later without holding idev. A refcount<br /> underflow issue for idev can be caused by this.<br /> <br /> if (!timer_pending(&amp;idev-&gt;rs_timer))<br /> in6_dev_hold(idev);<br /> rs_timer, jiffies + when);<br /> <br /> To fix the issue, hold idev if mod_timer() return 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix memory leaks in error path<br /> <br /> The memory allocated by vxlan_vnigroup_init() is not freed in the error<br /> path, leading to memory leaks [1]. Fix by calling<br /> vxlan_vnigroup_uninit() in the error path.<br /> <br /> The leaks can be reproduced by annotating gro_cells_init() with<br /> ALLOW_ERROR_INJECTION() and then running:<br /> <br /> # echo "100" &gt; /sys/kernel/debug/fail_function/probability<br /> # echo "1" &gt; /sys/kernel/debug/fail_function/times<br /> # echo "gro_cells_init" &gt; /sys/kernel/debug/fail_function/inject<br /> # printf %#x -12 &gt; /sys/kernel/debug/fail_function/gro_cells_init/retval<br /> # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter<br /> RTNETLINK answers: Cannot allocate memory<br /> <br /> [1]<br /> unreferenced object 0xffff88810db84a00 (size 512):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v.............<br /> 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H...........<br /> backtrace:<br /> [] kmalloc_trace+0x2a/0x60<br /> [] vxlan_vnigroup_init+0x4c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90<br /> [] ___sys_sendmsg+0x13a/0x1e0<br /> [] __sys_sendmsg+0x11c/0x1f0<br /> [] do_syscall_64+0x38/0x80<br /> unreferenced object 0xffff88810e76d5f8 (size 192):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O.....<br /> 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v.....<br /> backtrace:<br /> [] __kmalloc_node+0x4e/0x90<br /> [] kvmalloc_node+0xa6/0x1f0<br /> [] bucket_table_alloc.isra.0+0x83/0x460<br /> [] rhashtable_init+0x43b/0x7c0<br /> [] vxlan_vnigroup_init+0x6c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix nexthop hash size<br /> <br /> The nexthop code expects a 31 bit hash, such as what is returned by<br /> fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash<br /> returned by skb_get_hash() can lead to problems related to the fact that<br /> &amp;#39;int hash&amp;#39; is a negative number when the MSB is set.<br /> <br /> In the case of hash threshold nexthop groups, nexthop_select_path_hthr()<br /> will disproportionately select the first nexthop group entry. In the case<br /> of resilient nexthop groups, nexthop_select_path_res() may do an out of<br /> bounds access in nh_buckets[], for example:<br /> hash = -912054133<br /> num_nh_buckets = 2<br /> bucket_index = 65535<br /> <br /> which leads to the following panic:<br /> <br /> BUG: unable to handle page fault for address: ffffc900025910c8<br /> PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:nexthop_select_path+0x197/0xbf0<br /> Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85<br /> RSP: 0018:ffff88810c36f260 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8<br /> RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219<br /> R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0<br /> R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900<br /> FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x1ee/0x5c0<br /> ? __pfx_is_prefetch.constprop.0+0x10/0x10<br /> ? __pfx_page_fault_oops+0x10/0x10<br /> ? search_bpf_extables+0xfe/0x1c0<br /> ? fixup_exception+0x3b/0x470<br /> ? exc_page_fault+0xf6/0x110<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? lock_is_held_type+0xe7/0x140<br /> vxlan_xmit+0x5b2/0x2340<br /> ? __lock_acquire+0x92b/0x3370<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_register_lock_class+0x10/0x10<br /> ? skb_network_protocol+0xce/0x2d0<br /> ? dev_hard_start_xmit+0xca/0x350<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> dev_hard_start_xmit+0xca/0x350<br /> __dev_queue_xmit+0x513/0x1e20<br /> ? __pfx___dev_queue_xmit+0x10/0x10<br /> ? __pfx_lock_release+0x10/0x10<br /> ? mark_held_locks+0x44/0x90<br /> ? skb_push+0x4c/0x80<br /> ? eth_header+0x81/0xe0<br /> ? __pfx_eth_header+0x10/0x10<br /> ? neigh_resolve_output+0x215/0x310<br /> ? ip6_finish_output2+0x2ba/0xc90<br /> ip6_finish_output2+0x2ba/0xc90<br /> ? lock_release+0x236/0x3e0<br /> ? ip6_mtu+0xbb/0x240<br /> ? __pfx_ip6_finish_output2+0x10/0x10<br /> ? find_held_lock+0x83/0xa0<br /> ? lock_is_held_type+0xe7/0x140<br /> ip6_finish_output+0x1ee/0x780<br /> ip6_output+0x138/0x460<br /> ? __pfx_ip6_output+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_ip6_finish_output+0x10/0x10<br /> NF_HOOK.constprop.0+0xc0/0x420<br /> ? __pfx_NF_HOOK.constprop.0+0x10/0x10<br /> ? ndisc_send_skb+0x2c0/0x960<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __local_bh_enable_ip+0x93/0x110<br /> ? lock_is_held_type+0xe7/0x140<br /> ndisc_send_skb+0x4be/0x960<br /> ? __pfx_ndisc_send_skb+0x10/0x10<br /> ? mark_held_locks+0x65/0x90<br /> ? find_held_lock+0x83/0xa0<br /> ndisc_send_ns+0xb0/0x110<br /> ? __pfx_ndisc_send_ns+0x10/0x10<br /> addrconf_dad_work+0x631/0x8e0<br /> ? lock_acquire+0x180/0x3f0<br /> ? __pfx_addrconf_dad_work+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> process_one_work+0x582/0x9c0<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> worker_thread+0x93/0x630<br /> ? __kthread_parkme+0xdc/0x100<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1a5/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x60<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini<br /> <br /> The gmc.ecc_irq is enabled by firmware per IFWI setting,<br /> and the host driver is not privileged to enable/disable<br /> the interrupt. So, it is meaningless to use the amdgpu_irq_put<br /> function in gmc_v10_0_hw_fini, which also leads to the call<br /> trace.<br /> <br /> [ 82.340264] Call Trace:<br /> [ 82.340265] <br /> [ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu]<br /> [ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu]<br /> [ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu]<br /> [ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]<br /> [ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu]<br /> [ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu]<br /> [ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]<br /> [ 82.341529] process_one_work+0x21d/0x3f0<br /> [ 82.341535] worker_thread+0x1fa/0x3c0<br /> [ 82.341538] ? process_one_work+0x3f0/0x3f0<br /> [ 82.341540] kthread+0xff/0x130<br /> [ 82.341544] ? kthread_complete_and_exit+0x20/0x20<br /> [ 82.341547] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add length check in indx_get_root<br /> <br /> This adds a length check to guarantee the retrieved index root is legit.<br /> <br /> [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243<br /> [ 162.460851]<br /> [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42<br /> [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 162.462609] Call Trace:<br /> [ 162.462954] <br /> [ 162.463276] dump_stack_lvl+0x49/0x63<br /> [ 162.463822] print_report.cold+0xf5/0x689<br /> [ 162.464608] ? unwind_get_return_address+0x3a/0x60<br /> [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.466975] kasan_report+0xa7/0x130<br /> [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0<br /> [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.468536] __asan_load2+0x68/0x90<br /> [ 162.468923] hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.469282] ? cmp_uints+0xe0/0xe0<br /> [ 162.469557] ? cmp_sdh+0x90/0x90<br /> [ 162.469864] ? ni_find_attr+0x214/0x300<br /> [ 162.470217] ? ni_load_mi+0x80/0x80<br /> [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.470931] ? ntfs_bread_run+0x190/0x190<br /> [ 162.471307] ? indx_get_root+0xe4/0x190<br /> [ 162.471556] ? indx_get_root+0x140/0x190<br /> [ 162.471833] ? indx_init+0x1e0/0x1e0<br /> [ 162.472069] ? fnd_clear+0x115/0x140<br /> [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100<br /> [ 162.472731] indx_find+0x184/0x470<br /> [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0<br /> [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0<br /> [ 162.474704] ? do_syscall_64+0x3b/0x90<br /> [ 162.474962] dir_search_u+0x196/0x2f0<br /> [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450<br /> [ 162.475661] ? ntfs_security_init+0x3d6/0x440<br /> [ 162.475906] ? is_sd_valid+0x180/0x180<br /> [ 162.476191] ntfs_extend_init+0x13f/0x2c0<br /> [ 162.476496] ? ntfs_fix_post_read+0x130/0x130<br /> [ 162.476861] ? iput.part.0+0x286/0x320<br /> [ 162.477325] ntfs_fill_super+0x11e0/0x1b50<br /> [ 162.477709] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.477970] ? vsprintf+0x20/0x20<br /> [ 162.478258] ? set_blocksize+0x95/0x150<br /> [ 162.478538] get_tree_bdev+0x232/0x370<br /> [ 162.478789] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.479038] ntfs_fs_get_tree+0x15/0x20<br /> [ 162.479374] vfs_get_tree+0x4c/0x130<br /> [ 162.479729] path_mount+0x654/0xfe0<br /> [ 162.480124] ? putname+0x80/0xa0<br /> [ 162.480484] ? finish_automount+0x2e0/0x2e0<br /> [ 162.480894] ? putname+0x80/0xa0<br /> [ 162.481467] ? kmem_cache_free+0x1c4/0x440<br /> [ 162.482280] ? putname+0x80/0xa0<br /> [ 162.482714] do_mount+0xd6/0xf0<br /> [ 162.483264] ? path_mount+0xfe0/0xfe0<br /> [ 162.484782] ? __kasan_check_write+0x14/0x20<br /> [ 162.485593] __x64_sys_mount+0xca/0x110<br /> [ 162.486024] do_syscall_64+0x3b/0x90<br /> [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.487141] RIP: 0033:0x7f9d374e948a<br /> [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5<br /> [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a<br /> [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0<br /> [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020<br /> [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0<br /> [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 162.493644] <br /> [ 162.493908]<br /> [ 162.494214] The buggy address belongs to the physical page:<br /> [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc<br /> [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000<br /> [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000<br /> [ 162.500542] page dumped becau<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init<br /> <br /> The line cards array is not freed in the error path of<br /> mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by<br /> freeing the array in the error path, thereby making the error path<br /> identical to mlxsw_m_linecards_fini().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: qcom: Fix potential memory leak<br /> <br /> Function dwc3_qcom_probe() allocates memory for resource structure<br /> which is pointed by parent_res pointer. This memory is not<br /> freed. This leads to memory leak. Use stack memory to prevent<br /> memory leak.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Avoid NULL pointer access during management transmit cleanup<br /> <br /> Currently &amp;#39;ar&amp;#39; reference is not added in skb_cb.<br /> Though this is generally not used during transmit completion<br /> callbacks, on interface removal the remaining idr cleanup callback<br /> uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them<br /> during transmit call for proper usage to avoid NULL pointer dereference.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1