Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: Block access to folio overlimit<br /> <br /> syz reported a slab-out-of-bounds Write in fuse_dev_do_write.<br /> <br /> When the number of bytes to be retrieved is truncated to the upper limit<br /> by fc-&gt;max_pages and there is an offset, the oob is triggered.<br /> <br /> Add a loop termination condition to prevent overruns.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory<br /> <br /> When I did memory failure tests, below panic occurs:<br /> <br /> page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))<br /> kernel BUG at include/linux/page-flags.h:616!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40<br /> RIP: 0010:unpoison_memory+0x2f3/0x590<br /> RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246<br /> RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8<br /> RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0<br /> RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb<br /> R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000<br /> R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe<br /> FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> unpoison_memory+0x2f3/0x590<br /> simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110<br /> debugfs_attr_write+0x42/0x60<br /> full_proxy_write+0x5b/0x80<br /> vfs_write+0xd5/0x540<br /> ksys_write+0x64/0xe0<br /> do_syscall_64+0xb9/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f08f0314887<br /> RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887<br /> RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001<br /> RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009<br /> R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00<br /> <br /> Modules linked in: hwpoison_inject<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:unpoison_memory+0x2f3/0x590<br /> RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246<br /> RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8<br /> RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0<br /> RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb<br /> R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000<br /> R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe<br /> FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0<br /> Kernel panic - not syncing: Fatal exception<br /> Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)<br /> ---[ end Kernel panic - not syncing: Fatal exception ]---<br /> <br /> The root cause is that unpoison_memory() tries to check the PG_HWPoison<br /> flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is<br /> triggered. This can be reproduced by below steps:<br /> <br /> 1.Offline memory block:<br /> <br /> echo offline &gt; /sys/devices/system/memory/memory12/state<br /> <br /> 2.Get offlined memory pfn:<br /> <br /> page-types -b n -rlN<br /> <br /> 3.Write pfn to unpoison-pfn<br /> <br /> echo &gt; /sys/kernel/debug/hwpoison/unpoison-pfn<br /> <br /> This scenario can be identified by pfn_to_online_page() returning NULL. <br /> And ZONE_DEVICE pages are never expected, so we can simply fail if<br /> pfn_to_online_page() == NULL to fix the bug.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix recursive semaphore deadlock in fiemap call<br /> <br /> syzbot detected a OCFS2 hang due to a recursive semaphore on a<br /> FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.<br /> <br /> context_switch kernel/sched/core.c:5357 [inline]<br /> __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961<br /> __schedule_loop kernel/sched/core.c:7043 [inline]<br /> schedule+0x165/0x360 kernel/sched/core.c:7058<br /> schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115<br /> rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185<br /> __down_write_common kernel/locking/rwsem.c:1317 [inline]<br /> __down_write kernel/locking/rwsem.c:1326 [inline]<br /> down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591<br /> ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142<br /> do_page_mkwrite+0x14d/0x310 mm/memory.c:3361<br /> wp_page_shared mm/memory.c:3762 [inline]<br /> do_wp_page+0x268d/0x5800 mm/memory.c:3981<br /> handle_pte_fault mm/memory.c:6068 [inline]<br /> __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195<br /> handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364<br /> do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387<br /> handle_page_fault arch/x86/mm/fault.c:1476 [inline]<br /> exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532<br /> asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623<br /> RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]<br /> RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]<br /> RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]<br /> RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26<br /> Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89<br /> f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f<br /> 1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41<br /> RSP: 0018:ffffc9000403f950 EFLAGS: 00050256<br /> RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038<br /> RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060<br /> RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42<br /> R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098<br /> R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060<br /> copy_to_user include/linux/uaccess.h:225 [inline]<br /> fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145<br /> ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806<br /> ioctl_fiemap fs/ioctl.c:220 [inline]<br /> do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532<br /> __do_sys_ioctl fs/ioctl.c:596 [inline]<br /> __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5f13850fd9<br /> RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9<br /> RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004<br /> RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0<br /> R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b<br /> <br /> ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since<br /> v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the<br /> extent list of this running mmap executable. The user supplied buffer to<br /> hold the fiemap information page faults calling ocfs2_page_mkwrite() which<br /> will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same<br /> semaphore. This recursive semaphore will hold filesystem locks and causes<br /> a hang of the fileystem.<br /> <br /> The ip_alloc_sem protects the inode extent list and size. Release the<br /> read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()<br /> and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlock<br /> on the last extent but simplifies the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix crash after fscrypt_encrypt_pagecache_blocks() error<br /> <br /> The function move_dirty_folio_in_page_array() was created by commit<br /> ce80b76dd327 ("ceph: introduce ceph_process_folio_batch() method") by<br /> moving code from ceph_writepages_start() to this function.<br /> <br /> This new function is supposed to return an error code which is checked<br /> by the caller (now ceph_process_folio_batch()), and on error, the<br /> caller invokes redirty_page_for_writepage() and then breaks from the<br /> loop.<br /> <br /> However, the refactoring commit has gone wrong, and it by accident, it<br /> always returns 0 (= success) because it first NULLs the pointer and<br /> then returns PTR_ERR(NULL) which is always 0. This means errors are<br /> silently ignored, leaving NULL entries in the page array, which may<br /> later crash the kernel.<br /> <br /> The simple solution is to call PTR_ERR() before clearing the pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: always call ceph_shift_unused_folios_left()<br /> <br /> The function ceph_process_folio_batch() sets folio_batch entries to<br /> NULL, which is an illegal state. Before folio_batch_release() crashes<br /> due to this API violation, the function ceph_shift_unused_folios_left()<br /> is supposed to remove those NULLs from the array.<br /> <br /> However, since commit ce80b76dd327 ("ceph: introduce<br /> ceph_process_folio_batch() method"), this shifting doesn&amp;#39;t happen<br /> anymore because the "for" loop got moved to ceph_process_folio_batch(),<br /> and now the `i` variable that remains in ceph_writepages_start()<br /> doesn&amp;#39;t get incremented anymore, making the shifting effectively<br /> unreachable much of the time.<br /> <br /> Later, commit 1551ec61dc55 ("ceph: introduce ceph_submit_write()<br /> method") added more preconditions for doing the shift, replacing the<br /> `i` check (with something that is still just as broken):<br /> <br /> - if ceph_process_folio_batch() fails, shifting never happens<br /> <br /> - if ceph_move_dirty_page_in_page_array() was never called (because<br /> ceph_process_folio_batch() has returned early for some of various<br /> reasons), shifting never happens<br /> <br /> - if `processed_in_fbatch` is zero (because ceph_process_folio_batch()<br /> has returned early for some of the reasons mentioned above or<br /> because ceph_move_dirty_page_in_page_array() has failed), shifting<br /> never happens<br /> <br /> Since those two commits, any problem in ceph_process_folio_batch()<br /> could crash the kernel, e.g. this way:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000034<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0002 [#1] SMP NOPTI<br /> CPU: 172 UID: 0 PID: 2342707 Comm: kworker/u778:8 Not tainted 6.15.10-cm4all1-es #714 NONE<br /> Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.10 12/08/2023<br /> Workqueue: writeback wb_workfn (flush-ceph-1)<br /> RIP: 0010:folios_put_refs+0x85/0x140<br /> Code: 83 c5 01 39 e8 7e 76 48 63 c5 49 8b 5c c4 08 b8 01 00 00 00 4d 85 ed 74 05 41 8b 44 ad 00 48 8b 15 b0 &gt;<br /> RSP: 0018:ffffb880af8db778 EFLAGS: 00010207<br /> RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000003<br /> RDX: ffffe377cc3b0000 RSI: 0000000000000000 RDI: ffffb880af8db8c0<br /> RBP: 0000000000000000 R08: 000000000000007d R09: 000000000102b86f<br /> R10: 0000000000000001 R11: 00000000000000ac R12: ffffb880af8db8c0<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ffff9bd262c97000<br /> FS: 0000000000000000(0000) GS:ffff9c8efc303000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000034 CR3: 0000000160958004 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ceph_writepages_start+0xeb9/0x1410<br /> <br /> The crash can be reproduced easily by changing the<br /> ceph_check_page_before_write() return value to `-E2BIG`.<br /> <br /> (Interestingly, the crash happens only if `huge_zero_folio` has<br /> already been allocated; without `huge_zero_folio`,<br /> is_huge_zero_folio(NULL) returns true and folios_put_refs() skips NULL<br /> entries instead of dereferencing them. That makes reproducing the bug<br /> somewhat unreliable. See<br /> https://lore.kernel.org/20250826231626.218675-1-max.kellermann@ionos.com<br /> for a discussion of this detail.)<br /> <br /> My suggestion is to move the ceph_shift_unused_folios_left() to right<br /> after ceph_process_folio_batch() to ensure it always gets called to<br /> fix up the illegal folio_batch state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: fix potential OF node use-after-free<br /> <br /> The for_each_child_of_node() helper drops the reference it takes to each<br /> node as it iterates over children and an explicit of_node_put() is only<br /> needed when exiting the loop early.<br /> <br /> Drop the recently introduced bogus additional reference count decrement<br /> at each iteration that could potentially lead to a use-after-free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernfs: Fix UAF in polling when open file is released<br /> <br /> A use-after-free (UAF) vulnerability was identified in the PSI (Pressure<br /> Stall Information) monitoring mechanism:<br /> <br /> BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140<br /> Read of size 8 at addr ffff3de3d50bd308 by task systemd/1<br /> <br /> psi_trigger_poll+0x3c/0x140<br /> cgroup_pressure_poll+0x70/0xa0<br /> cgroup_file_poll+0x8c/0x100<br /> kernfs_fop_poll+0x11c/0x1c0<br /> ep_item_poll.isra.0+0x188/0x2c0<br /> <br /> Allocated by task 1:<br /> cgroup_file_open+0x88/0x388<br /> kernfs_fop_open+0x73c/0xaf0<br /> do_dentry_open+0x5fc/0x1200<br /> vfs_open+0xa0/0x3f0<br /> do_open+0x7e8/0xd08<br /> path_openat+0x2fc/0x6b0<br /> do_filp_open+0x174/0x368<br /> <br /> Freed by task 8462:<br /> cgroup_file_release+0x130/0x1f8<br /> kernfs_drain_open_files+0x17c/0x440<br /> kernfs_drain+0x2dc/0x360<br /> kernfs_show+0x1b8/0x288<br /> cgroup_file_show+0x150/0x268<br /> cgroup_pressure_write+0x1dc/0x340<br /> cgroup_file_write+0x274/0x548<br /> <br /> Reproduction Steps:<br /> 1. Open test/cpu.pressure and establish epoll monitoring<br /> 2. Disable monitoring: echo 0 &gt; test/cgroup.pressure<br /> 3. Re-enable monitoring: echo 1 &gt; test/cgroup.pressure<br /> <br /> The race condition occurs because:<br /> 1. When cgroup.pressure is disabled (echo 0 &gt; cgroup.pressure), it:<br /> - Releases PSI triggers via cgroup_file_release()<br /> - Frees of-&gt;priv through kernfs_drain_open_files()<br /> 2. While epoll still holds reference to the file and continues polling<br /> 3. Re-enabling (echo 1 &gt; cgroup.pressure) accesses freed of-&gt;priv<br /> <br /> epolling disable/enable cgroup.pressure<br /> fd=open(cpu.pressure)<br /> while(1)<br /> ...<br /> epoll_wait<br /> kernfs_fop_poll<br /> kernfs_get_active = true echo 0 &gt; cgroup.pressure<br /> ... cgroup_file_show<br /> kernfs_show<br /> // inactive kn<br /> kernfs_drain_open_files<br /> cft-&gt;release(of);<br /> kfree(ctx);<br /> ...<br /> kernfs_get_active = false<br /> echo 1 &gt; cgroup.pressure<br /> kernfs_show<br /> kernfs_activate_one(kn);<br /> kernfs_fop_poll<br /> kernfs_get_active = true<br /> cgroup_file_poll<br /> psi_trigger_poll<br /> // UAF<br /> ...<br /> end: close(fd)<br /> <br /> To address this issue, introduce kernfs_get_active_of() for kernfs open<br /> files to obtain active references. This function will fail if the open file<br /> has been released. Replace kernfs_get_active() with kernfs_get_active_of()<br /> to prevent further operations on released file descriptors.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix invalid accesses to ceph_connection_v1_info<br /> <br /> There is a place where generic code in messenger.c is reading and<br /> another place where it is writing to con-&gt;v1 union member without<br /> checking that the union member is active (i.e. msgr1 is in use).<br /> <br /> On 64-bit systems, con-&gt;v1.auth_retry overlaps with con-&gt;v2.out_iter,<br /> so such a read is almost guaranteed to return a bogus value instead of<br /> 0 when msgr2 is in use. This ends up being fairly benign because the<br /> side effect is just the invalidation of the authorizer and successive<br /> fetching of new tickets.<br /> <br /> con-&gt;v1.connect_seq overlaps with con-&gt;v2.conn_bufs and the fact that<br /> it&amp;#39;s being written to can cause more serious consequences, but luckily<br /> it&amp;#39;s not something that happens often.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: fix use-after-free in state_show()<br /> <br /> state_show() reads kdamond-&gt;damon_ctx without holding damon_sysfs_lock. <br /> This allows a use-after-free race:<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> state_show() damon_sysfs_turn_damon_on()<br /> ctx = kdamond-&gt;damon_ctx; mutex_lock(&amp;damon_sysfs_lock);<br /> damon_destroy_ctx(kdamond-&gt;damon_ctx);<br /> kdamond-&gt;damon_ctx = NULL;<br /> mutex_unlock(&amp;damon_sysfs_lock);<br /> damon_is_running(ctx); /* ctx is freed */<br /> mutex_lock(&amp;ctx-&gt;kdamond_lock); /* UAF */<br /> <br /> (The race can also occur with damon_sysfs_kdamonds_rm_dirs() and<br /> damon_sysfs_kdamond_release(), which free or replace the context under<br /> damon_sysfs_lock.)<br /> <br /> Fix by taking damon_sysfs_lock before dereferencing the context, mirroring<br /> the locking used in pid_show().<br /> <br /> The bug has existed since state_show() first accessed kdamond-&gt;damon_ctx.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()<br /> <br /> The function of_phy_find_device may return NULL, so we need to take<br /> care before dereferencing phy_dev.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: hold rcu and dev lock for hsr_get_port_ndev<br /> <br /> hsr_get_port_ndev calls hsr_for_each_port, which need to hold rcu lock.<br /> On the other hand, before return the port device, we need to hold the<br /> device reference to avoid UaF in the caller function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Remove improper idxd_free<br /> <br /> The call to idxd_free() introduces a duplicate put_device() leading to a<br /> reference count underflow:<br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110<br /> ...<br /> Call Trace:<br /> <br /> idxd_remove+0xe4/0x120 [idxd]<br /> pci_device_remove+0x3f/0xb0<br /> device_release_driver_internal+0x197/0x200<br /> driver_detach+0x48/0x90<br /> bus_remove_driver+0x74/0xf0<br /> pci_unregister_driver+0x2e/0xb0<br /> idxd_exit_module+0x34/0x7a0 [idxd]<br /> __do_sys_delete_module.constprop.0+0x183/0x280<br /> do_syscall_64+0x54/0xd70<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The idxd_unregister_devices() which is invoked at the very beginning of<br /> idxd_remove(), already takes care of the necessary put_device() through the<br /> following call path:<br /> idxd_unregister_devices() -&gt; device_unregister() -&gt; put_device()<br /> <br /> In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() may<br /> trigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() is<br /> called immediately after, it can result in a use-after-free.<br /> <br /> Remove the improper idxd_free() to avoid both the refcount underflow and<br /> potential memory corruption during module unload.