Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions<br /> <br /> While running the self-tests on a KASAN enabled kernel, I observed a<br /> slab-out-of-bounds splat very similar to the one reported in<br /> commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in<br /> fib6_nh_flush_exceptions").<br /> <br /> We additionally need to take care of fib6_metrics initialization<br /> failure when the caller provides an nh.<br /> <br /> The fix is similar, explicitly free the route instead of calling<br /> fib6_info_release on a half-initialized object.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix memleak in io_init_wq_offload()<br /> <br /> I got memory leak report when doing fuzz test:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff888107310a80 (size 96):<br /> comm "syz-executor.6", pid 4610, jiffies 4295140240 (age 20.135s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> backtrace:<br /> [] kmalloc include/linux/slab.h:591 [inline]<br /> [] kzalloc include/linux/slab.h:721 [inline]<br /> [] io_init_wq_offload fs/io_uring.c:7920 [inline]<br /> [] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955<br /> [] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016<br /> [] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]<br /> [] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]<br /> [] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]<br /> [] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301<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+0x44/0xae<br /> <br /> CPU0 CPU1<br /> io_uring_enter io_uring_enter<br /> io_uring_add_tctx_node io_uring_add_tctx_node<br /> __io_uring_add_tctx_node __io_uring_add_tctx_node<br /> io_uring_alloc_task_context io_uring_alloc_task_context<br /> io_init_wq_offload io_init_wq_offload<br /> hash = kzalloc hash = kzalloc<br /> ctx-&gt;hash_map = hash ctx-&gt;hash_map = hash

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_skbmod: Skip non-Ethernet packets<br /> <br /> Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2<br /> protocol, which is not always the case. As an example, for CAN devices:<br /> <br /> $ ip link add dev vcan0 type vcan<br /> $ ip link set up vcan0<br /> $ tc qdisc add dev vcan0 root handle 1: htb<br /> $ tc filter add dev vcan0 parent 1: protocol ip prio 10 \<br /> matchall action skbmod swap mac<br /> <br /> Doing the above silently corrupts all the packets. Do not perform skbmod<br /> actions for non-Ethernet packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netrom: Decrease sock refcount when sock timers expire<br /> <br /> Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use<br /> sock timer API. It replaces mod_timer() by sk_reset_timer(), and<br /> del_timer() by sk_stop_timer().<br /> <br /> Function sk_reset_timer() will increase the refcount of sock if it is<br /> called on an inactive timer, hence, in case the timer expires, we need to<br /> decrease the refcount ourselves in the handler, otherwise, the sock<br /> refcount will be unbalanced and the sock will never be freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak<br /> <br /> vcpu_put is not called if the user copy fails. This can result in preempt<br /> notifier corruption and crashes, among other issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix uninit-value in caif_seqpkt_sendmsg<br /> <br /> When nr_segs equal to zero in iovec_from_user, the object<br /> msg-&gt;msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg<br /> which is defined in ___sys_sendmsg. So we cann&amp;#39;t just judge<br /> msg-&gt;msg_iter.iov-&gt;base directlly. We can use nr_segs to judge<br /> msg in caif_seqpkt_sendmsg whether has data buffers.<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x1c9/0x220 lib/dump_stack.c:118<br /> kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118<br /> __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215<br /> caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542<br /> sock_sendmsg_nosec net/socket.c:652 [inline]<br /> sock_sendmsg net/socket.c:672 [inline]<br /> ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343<br /> ___sys_sendmsg net/socket.c:2397 [inline]<br /> __sys_sendmmsg+0x808/0xc90 net/socket.c:2480<br /> __compat_sys_sendmmsg net/compat.c:656 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix potential memory leak on unlikely error case<br /> <br /> If skb_linearize is needed and fails we could leak a msg on the error<br /> handling. To fix ensure we kfree the msg block before returning error.<br /> Found during code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp, net: Fix use-after-free in bpf_xdp_link_release<br /> <br /> The problem occurs between dev_get_by_index() and dev_xdp_attach_link().<br /> At this point, dev_xdp_uninstall() is called. Then xdp link will not be<br /> detached automatically when dev is released. But link-&gt;dev already<br /> points to dev, when xdp link is released, dev will still be accessed,<br /> but dev has been released.<br /> <br /> dev_get_by_index() |<br /> link-&gt;dev = dev |<br /> | rtnl_lock()<br /> | unregister_netdevice_many()<br /> | dev_xdp_uninstall()<br /> | rtnl_unlock()<br /> rtnl_lock(); |<br /> dev_xdp_attach_link() |<br /> rtnl_unlock(); |<br /> | netdev_run_todo() // dev released<br /> bpf_xdp_link_release() |<br /> /* access dev. |<br /> use-after-free */ |<br /> <br /> [ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0<br /> [ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732<br /> [ 45.968297]<br /> [ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22<br /> [ 45.969222] Hardware name: linux,dummy-virt (DT)<br /> [ 45.969795] Call trace:<br /> [ 45.970106] dump_backtrace+0x0/0x4c8<br /> [ 45.970564] show_stack+0x30/0x40<br /> [ 45.970981] dump_stack_lvl+0x120/0x18c<br /> [ 45.971470] print_address_description.constprop.0+0x74/0x30c<br /> [ 45.972182] kasan_report+0x1e8/0x200<br /> [ 45.972659] __asan_report_load8_noabort+0x2c/0x50<br /> [ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0<br /> [ 45.973834] bpf_link_free+0xd0/0x188<br /> [ 45.974315] bpf_link_put+0x1d0/0x218<br /> [ 45.974790] bpf_link_release+0x3c/0x58<br /> [ 45.975291] __fput+0x20c/0x7e8<br /> [ 45.975706] ____fput+0x24/0x30<br /> [ 45.976117] task_work_run+0x104/0x258<br /> [ 45.976609] do_notify_resume+0x894/0xaf8<br /> [ 45.977121] work_pending+0xc/0x328<br /> [ 45.977575]<br /> [ 45.977775] The buggy address belongs to the page:<br /> [ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998<br /> [ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)<br /> [ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000<br /> [ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 45.982259] page dumped because: kasan: bad access detected<br /> [ 45.982948]<br /> [ 45.983153] Memory state around the buggy address:<br /> [ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.985533] &gt;ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.986419] ^<br /> [ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.988895] ==================================================================<br /> [ 45.989773] Disabling lock debugging due to kernel taint<br /> [ 45.990552] Kernel panic - not syncing: panic_on_warn set ...<br /> [ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22<br /> [ 45.991929] Hardware name: linux,dummy-virt (DT)<br /> [ 45.992448] Call trace:<br /> [ 45.992753] dump_backtrace+0x0/0x4c8<br /> [ 45.993208] show_stack+0x30/0x40<br /> [ 45.993627] dump_stack_lvl+0x120/0x18c<br /> [ 45.994113] dump_stack+0x1c/0x34<br /> [ 45.994530] panic+0x3a4/0x7d8<br /> [ 45.994930] end_report+0x194/0x198<br /> [ 45.995380] kasan_report+0x134/0x200<br /> [ 45.995850] __asan_report_load8_noabort+0x2c/0x50<br /> [ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0<br /> [ 45.997007] bpf_link_free+0xd0/0x188<br /> [ 45.997474] bpf_link_put+0x1d0/0x218<br /> [ 45.997942] bpf_link_release+0x3c/0x58<br /> [ 45.998429] __fput+0x20c/0x7e8<br /> [ 45.998833] ____fput+0x24/0x30<br /> [ 45.999247] task_work_run+0x104/0x258<br /> [ 45.999731] do_notify_resume+0x894/0xaf8<br /> [ 46.000236] work_pending<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix tail_call_reachable rejection for interpreter when jit failed<br /> <br /> During testing of f263a81451c1 ("bpf: Track subprog poke descriptors correctly<br /> and fix use-after-free") under various failure conditions, for example, when<br /> jit_subprogs() fails and tries to clean up the program to be run under the<br /> interpreter, we ran into the following freeze:<br /> <br /> [...]<br /> #127/8 tailcall_bpf2bpf_3:FAIL<br /> [...]<br /> [ 92.041251] BUG: KASAN: slab-out-of-bounds in ___bpf_prog_run+0x1b9d/0x2e20<br /> [ 92.042408] Read of size 8 at addr ffff88800da67f68 by task test_progs/682<br /> [ 92.043707]<br /> [ 92.044030] CPU: 1 PID: 682 Comm: test_progs Tainted: G O 5.13.0-53301-ge6c08cb33a30-dirty #87<br /> [ 92.045542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014<br /> [ 92.046785] Call Trace:<br /> [ 92.047171] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.047773] ? __bpf_prog_run_args32+0x8b/0xb0<br /> [ 92.048389] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.049019] ? ktime_get+0x117/0x130<br /> [...] // few hundred [similar] lines more<br /> [ 92.659025] ? ktime_get+0x117/0x130<br /> [ 92.659845] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.660738] ? __bpf_prog_run_args32+0x8b/0xb0<br /> [ 92.661528] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.662378] ? print_usage_bug+0x50/0x50<br /> [ 92.663221] ? print_usage_bug+0x50/0x50<br /> [ 92.664077] ? bpf_ksym_find+0x9c/0xe0<br /> [ 92.664887] ? ktime_get+0x117/0x130<br /> [ 92.665624] ? kernel_text_address+0xf5/0x100<br /> [ 92.666529] ? __kernel_text_address+0xe/0x30<br /> [ 92.667725] ? unwind_get_return_address+0x2f/0x50<br /> [ 92.668854] ? ___bpf_prog_run+0x15d4/0x2e20<br /> [ 92.670185] ? ktime_get+0x117/0x130<br /> [ 92.671130] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.672020] ? __bpf_prog_run_args32+0x8b/0xb0<br /> [ 92.672860] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.675159] ? ktime_get+0x117/0x130<br /> [ 92.677074] ? lock_is_held_type+0xd5/0x130<br /> [ 92.678662] ? ___bpf_prog_run+0x15d4/0x2e20<br /> [ 92.680046] ? ktime_get+0x117/0x130<br /> [ 92.681285] ? __bpf_prog_run32+0x6b/0x90<br /> [ 92.682601] ? __bpf_prog_run64+0x90/0x90<br /> [ 92.683636] ? lock_downgrade+0x370/0x370<br /> [ 92.684647] ? mark_held_locks+0x44/0x90<br /> [ 92.685652] ? ktime_get+0x117/0x130<br /> [ 92.686752] ? lockdep_hardirqs_on+0x79/0x100<br /> [ 92.688004] ? ktime_get+0x117/0x130<br /> [ 92.688573] ? __cant_migrate+0x2b/0x80<br /> [ 92.689192] ? bpf_test_run+0x2f4/0x510<br /> [ 92.689869] ? bpf_test_timer_continue+0x1c0/0x1c0<br /> [ 92.690856] ? rcu_read_lock_bh_held+0x90/0x90<br /> [ 92.691506] ? __kasan_slab_alloc+0x61/0x80<br /> [ 92.692128] ? eth_type_trans+0x128/0x240<br /> [ 92.692737] ? __build_skb+0x46/0x50<br /> [ 92.693252] ? bpf_prog_test_run_skb+0x65e/0xc50<br /> [ 92.693954] ? bpf_prog_test_run_raw_tp+0x2d0/0x2d0<br /> [ 92.694639] ? __fget_light+0xa1/0x100<br /> [ 92.695162] ? bpf_prog_inc+0x23/0x30<br /> [ 92.695685] ? __sys_bpf+0xb40/0x2c80<br /> [ 92.696324] ? bpf_link_get_from_fd+0x90/0x90<br /> [ 92.697150] ? mark_held_locks+0x24/0x90<br /> [ 92.698007] ? lockdep_hardirqs_on_prepare+0x124/0x220<br /> [ 92.699045] ? finish_task_switch+0xe6/0x370<br /> [ 92.700072] ? lockdep_hardirqs_on+0x79/0x100<br /> [ 92.701233] ? finish_task_switch+0x11d/0x370<br /> [ 92.702264] ? __switch_to+0x2c0/0x740<br /> [ 92.703148] ? mark_held_locks+0x24/0x90<br /> [ 92.704155] ? __x64_sys_bpf+0x45/0x50<br /> [ 92.705146] ? do_syscall_64+0x35/0x80<br /> [ 92.706953] ? entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [...]<br /> <br /> Turns out that the program rejection from e411901c0b77 ("bpf: allow for tailcalls<br /> in BPF subprograms for x64 JIT") is buggy since env-&gt;prog-&gt;aux-&gt;tail_call_reachable<br /> is never true. Commit ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall<br /> handling in JIT") added a tracker into check_max_stack_depth() which propagates<br /> the tail_call_reachable condition throughout the subprograms. This info is then<br /> assigned to the subprogram&amp;#39;s <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Fix use-after-free error during reset<br /> <br /> Cleans the next descriptor to watch (next_to_watch) when cleaning the<br /> TX ring.<br /> <br /> Failure to do so can cause invalid memory accesses. If igb_poll() runs<br /> while the controller is reset this can lead to the driver try to free<br /> a skb that was already freed.<br /> <br /> (The crash is harder to reproduce with the igb driver, but the same<br /> potential problem exists as the code is identical to igc)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: Fix use-after-free error during reset<br /> <br /> Cleans the next descriptor to watch (next_to_watch) when cleaning the<br /> TX ring.<br /> <br /> Failure to do so can cause invalid memory accesses. If igc_poll() runs<br /> while the controller is being reset this can lead to the driver try to<br /> free a skb that was already freed.<br /> <br /> Log message:<br /> <br /> [ 101.525242] refcount_t: underflow; use-after-free.<br /> [ 101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0<br /> [ 101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)<br /> x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)<br /> ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)<br /> rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)<br /> soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)<br /> iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)<br /> soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)<br /> autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)<br /> i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)<br /> [ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)<br /> e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)<br /> usbcore(E) drm(E) button(E) video(E)<br /> [ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G E 5.10.30-rt37-tsn1-rt-ipipe #ipipe<br /> [ 101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017<br /> [ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0<br /> [ 101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48<br /> 44 01 01 e8 d1 c6 42 00 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3<br /> [ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286<br /> [ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001<br /> [ 101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff<br /> [ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50<br /> [ 101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00<br /> [ 101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40<br /> [ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000<br /> [ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0<br /> [ 101.525343] Call Trace:<br /> [ 101.525346] sock_wfree+0x9c/0xa0<br /> [ 101.525353] unix_destruct_scm+0x7b/0xa0<br /> [ 101.525358] skb_release_head_state+0x40/0x90<br /> [ 101.525362] skb_release_all+0xe/0x30<br /> [ 101.525364] napi_consume_skb+0x57/0x160<br /> [ 101.525367] igc_poll+0xb7/0xc80 [igc]<br /> [ 101.525376] ? sched_clock+0x5/0x10<br /> [ 101.525381] ? sched_clock_cpu+0xe/0x100<br /> [ 101.525385] net_rx_action+0x14c/0x410<br /> [ 101.525388] __do_softirq+0xe9/0x2f4<br /> [ 101.525391] __local_bh_enable_ip+0xe3/0x110<br /> [ 101.525395] ? irq_finalize_oneshot.part.47+0xe0/0xe0<br /> [ 101.525398] irq_forced_thread_fn+0x6a/0x80<br /> [ 101.525401] irq_thread+0xe8/0x180<br /> [ 101.525403] ? wake_threads_waitq+0x30/0x30<br /> [ 101.525406] ? irq_thread_check_affinity+0xd0/0xd0<br /> [ 101.525408] kthread+0x183/0x1a0<br /> [ 101.525412] ? kthread_park+0x80/0x80<br /> [ 101.525415] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix memory leak in tcindex_partial_destroy_work<br /> <br /> Syzbot reported memory leak in tcindex_set_parms(). The problem was in<br /> non-freed perfect hash in tcindex_partial_destroy_work().<br /> <br /> In tcindex_set_parms() new tcindex_data is allocated and some fields from<br /> old one are copied to new one, but not the perfect hash. Since<br /> tcindex_partial_destroy_work() is the destroy function for old<br /> tcindex_data, we need to free perfect hash to avoid memory leak.