Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix memory leak in btrfs_do_encoded_write()<br /> <br /> Local fuzzing of 6.12.94 has found the following memory leak:<br /> <br /> Unreferenced object 0xffff888018050a80 (size 64):<br /> comm "syz.0.17", pid 10297, jiffies 4294953601<br /> hex dump (first 32 bytes):<br /> 00 10 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................<br /> 10 0a 05 18 80 88 ff ff 10 0a 05 18 80 88 ff ff ................<br /> backtrace (crc a8a6fc29):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]<br /> slab_post_alloc_hook mm/slub.c:4152 [inline]<br /> slab_alloc_node mm/slub.c:4197 [inline]<br /> __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358<br /> kmalloc_noprof include/linux/slab.h:878 [inline]<br /> extent_changeset_alloc fs/btrfs/extent_io.h:207 [inline]<br /> qgroup_reserve_data+0x1c5/0x7d0 fs/btrfs/qgroup.c:4305<br /> btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355<br /> btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746<br /> btrfs_encoded_write fs/btrfs/file.c:1482 [inline]<br /> btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507<br /> btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738<br /> btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:47 [inline]<br /> do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Unreferenced object 0xffff888018050a00 (size 64):<br /> comm "syz.0.17", pid 10297, jiffies 4294953601<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 ................<br /> 90 0a 05 18 80 88 ff ff 90 0a 05 18 80 88 ff ff ................<br /> backtrace (crc cb5c9580):<br /> kmemleak_alloc_recursive include/linux/kmemleak.h:42 [inline]<br /> slab_post_alloc_hook mm/slub.c:4152 [inline]<br /> slab_alloc_node mm/slub.c:4197 [inline]<br /> __kmalloc_cache_noprof+0x168/0x2c0 mm/slub.c:4358<br /> kmalloc_noprof include/linux/slab.h:878 [inline]<br /> kzalloc_noprof include/linux/slab.h:1014 [inline]<br /> ulist_prealloc+0x9c/0x110 fs/btrfs/ulist.c:114<br /> extent_changeset_prealloc fs/btrfs/extent_io.h:217 [inline]<br /> __set_extent_bit+0x16b/0x1a70 fs/btrfs/extent-io-tree.c:1086<br /> set_record_extent_bits+0x50/0x90 fs/btrfs/extent-io-tree.c:1821<br /> qgroup_reserve_data+0x274/0x7d0 fs/btrfs/qgroup.c:4312<br /> btrfs_qgroup_reserve_data+0x2e/0xb0 fs/btrfs/qgroup.c:4355<br /> btrfs_do_encoded_write+0x92e/0x1040 fs/btrfs/inode.c:9746<br /> btrfs_encoded_write fs/btrfs/file.c:1482 [inline]<br /> btrfs_do_write_iter+0x280/0x610 fs/btrfs/file.c:1507<br /> btrfs_ioctl_encoded_write+0x3d6/0x490 fs/btrfs/ioctl.c:4738<br /> btrfs_ioctl+0x6f9/0xc90 fs/btrfs/ioctl.c:-1<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:47 [inline]<br /> do_syscall_64+0xbe/0x1a0 arch/x86/entry/common.c:78<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Fix this by freeing an extent changeset before returning from<br /> btrfs_do_encoded_write().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: lzo: reject inline extents without valid headers<br /> <br /> [BUG]<br /> For a crafted btrfs image, the following KASAN can be triggered when<br /> reading an inline lzo compressed file extent:<br /> <br /> BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700<br /> Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5b/0x70<br /> print_report+0xd1/0x610<br /> kasan_report+0xe0/0x110<br /> __asan_report_load_n_noabort+0x13/0x20<br /> lzo_decompress+0x57d/0x700<br /> btrfs_decompress+0x140/0x1c0<br /> uncompress_inline+0x147/0x1b0<br /> btrfs_get_extent+0xb23/0x10a0<br /> btrfs_do_readpage.constprop.0+0x538/0x1ac0<br /> btrfs_readahead+0x32f/0x5f0<br /> read_pages+0x16f/0x850<br /> page_cache_ra_unbounded+0x296/0x490<br /> do_page_cache_ra+0xd9/0x130<br /> page_cache_sync_ra+0x3ee/0x6f0<br /> filemap_get_pages+0x306/0x15c0<br /> filemap_read+0x329/0xd00<br /> btrfs_file_read_iter+0x1f8/0x2b0<br /> vfs_read+0x4ef/0x720<br /> ksys_read+0xf8/0x1d0<br /> __x64_sys_read+0x71/0xb0<br /> x64_sys_call+0x1ab0/0x1b70<br /> do_syscall_64+0x61/0x470<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> <br /> [CAUSE]<br /> For an inline lzo compressed file extent, there should always be one lzo<br /> header, recording the total length of the compressed data, followed by<br /> one segment header, recording the compressed lzo payload.<br /> <br /> But if a crafted inline lzo compressed file extent contains only an lzo<br /> header, without the segment header or payload, lzo_decompress() will<br /> still try to read the segment header, causing a read beyond the item<br /> boundary.<br /> <br /> Furthermore if the inline lzo compressed file extent is the first item<br /> of the leaf, it will be at the extent buffer boundary. The above<br /> out-of-boundary read will go beyond the extent buffer boundary,<br /> triggering the above KASAN report.<br /> <br /> [FIX]<br /> Validate the total length of the inlined lzo compressed file extent, to<br /> make sure there is at least one LZO header and one segment header, and a<br /> non-zero payload.<br /> <br /> [ Rework the commit message to remove slop ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: avoid out-of-bounds write in ip_vs_nat_icmp<br /> <br /> Sashiko warns that local attacker can modify the packet<br /> while it is processed by IPVS. Some places read the<br /> IP ihl field multiple times which can cause out-of-bounds<br /> access. One such place is ip_vs_nat_icmp where we<br /> can write after the validated area.<br /> <br /> Fix it by providing ciph argument just like it is done for<br /> IPv6 and use ciph-&gt;len as offset to the embedded transport<br /> header.<br /> <br /> Modify some IPv4 header checks by reading the ihl field<br /> only once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> enic: fix tx_hang_reset use-after-free on device removal<br /> <br /> enic_remove() cancels the reset and change_mtu_work items but does not<br /> cancel tx_hang_reset. A TX timeout that fires while the device is being<br /> removed can schedule enic_tx_hang_reset() so that it runs after<br /> free_netdev(), resulting in a use-after-free.<br /> <br /> cancel_work_sync() alone is not sufficient here: the still-live watchdog<br /> and notify paths can re-schedule these work items in the window between<br /> the cancel and unregister_netdev(). Use disable_work_sync(), which<br /> cancels the work and blocks any subsequent schedule_work() from<br /> requeuing it, and apply it to the reset and change_mtu_work items as<br /> well so the same requeue race is closed for all teardown work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor<br /> <br /> bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and<br /> takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the<br /> active slave. In that window the active slave can change under RTNL<br /> (RTM_DELLINK -&gt; __bond_release_one() -&gt; bond_alb_handle_active_change()),<br /> which already drops the promiscuity and clears primary_is_promisc. The<br /> monitor still acts on the stale decision: if the slave was removed with no<br /> failover, curr_active_slave is now NULL and the deref faults; if it failed<br /> over, the stale dev_set_promiscuity(-1) underflows the new slave&amp;#39;s<br /> promiscuity counter and pins it in IFF_PROMISC.<br /> <br /> Oops: general protection fault, probably for non-canonical address ...<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> Workqueue: b42 bond_alb_monitor<br /> RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600)<br /> process_one_work (kernel/workqueue.c:3322)<br /> worker_thread (kernel/workqueue.c:3486)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so<br /> the monitor only undoes an increment it still owns. The other bonding<br /> monitors already re-read state under RTNL in their commit phase<br /> (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only<br /> one acting on the pre-trylock decision.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: skip rehash for peers already removed from by_id<br /> <br /> ovpn_nl_peer_set_doit() resolves the target peer via<br /> ovpn_peer_get_by_id() before taking ovpn-&gt;lock. In the window between<br /> the lookup (which only takes a refcount) and the subsequent<br /> spin_lock_bh(&amp;ovpn-&gt;lock), a concurrent OVPN_CMD_PEER_DEL, keepalive<br /> expiry, or socket teardown can take ovpn-&gt;lock first, run<br /> ovpn_peer_remove() to unhash the peer from all four tables (by_id,<br /> by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then<br /> acquires ovpn-&gt;lock and calls ovpn_peer_hash_vpn_ip(), which<br /> re-inserts the now-removed peer back into the rehashing tables.<br /> <br /> The same race affects the float path: ovpn_peer_endpoints_update()<br /> holds only a refcount and acquires ovpn-&gt;lock very late (after async<br /> AEAD decrypt and a netlink notification), then rehashes the peer<br /> in the by_transp_addr table.<br /> <br /> The resurrected peer becomes reachable again from the RX lookup<br /> (ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though<br /> userspace believes it is gone. Once the data-path refcount drops the<br /> peer is freed via call_rcu while the hash entries embedded in it<br /> remain linked, opening a UAF window.<br /> <br /> Bail out of the rehash when hash_entry_id is unhashed, mirroring<br /> the sentinel already used by ovpn_peer_remove() to detect the<br /> already-removed state. The check is safe under ovpn-&gt;lock, which<br /> serializes every mutation of hash_entry_id, and is a no-op for the<br /> add path because ovpn_peer_add_mp() inserts hash_entry_id before<br /> calling ovpn_peer_hash_vpn_ip().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: handle NULL b_addr in xfs_buf_free<br /> <br /> When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with<br /> bp-&gt;b_addr still NULL. The code falls through to the folio_put path<br /> which calls virt_to_folio(NULL), dereferencing an invalid address and<br /> causing a kernel crash.<br /> <br /> Call Trace:<br /> xfs_buf_free+0x25f/0x510<br /> xfs_buf_alloc+0xc98/0x19b0<br /> xfs_buf_find_insert+0x55/0x14d0<br /> xfs_buf_get_map+0x122b/0x17c0<br /> xfbtree_init_leaf_block+0x11c/0x4a0<br /> xfbtree_init+0x1bb/0x460<br /> xrep_rmap_setup_scan+0x100/0x1f0<br /> xrep_rmapbt+0x41/0xc0<br /> <br /> Fix this by skipping folio_put() when bp-&gt;b_addr is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost_iotlb: bound map allocation in add_range<br /> <br /> vhost_iotlb_add_range_ctx() only retires an old entry when the table<br /> has a non-zero limit, has exactly reached that limit and has<br /> VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating<br /> entries after reaching their configured limit.<br /> <br /> Existing vhost devices allocate their IOTLB with max_iotlb_entries from<br /> vhost.c, which defaults to 2048 and is tunable by module parameter. Use<br /> the caller-provided limit at the allocation point instead of adding a<br /> separate default in the common IOTLB helper, and reject non-positive<br /> values in vhost paths that can report an error.<br /> <br /> Other vhost IOTLB users should not create zero-limit tables when entries<br /> can be populated from userspace or guest-controlled requests. Add<br /> caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and<br /> vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require<br /> at least two entries for vdpa_sim and mlx5 vDPA paths that install<br /> full-range mappings, since those mappings are split into two IOTLB<br /> entries.<br /> <br /> Handle full-range mappings in the common helper by checking that the<br /> IOTLB can hold both split entries before inserting the first half. This<br /> avoids returning an error after leaving a half mapping behind.<br /> <br /> When the table is full, keep the existing retire behavior for retiring<br /> tables and return -ENOSPC for non-retiring tables. Reuse the retired map<br /> node instead of freeing it and allocating a replacement, so a stream of<br /> IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table<br /> has reached its limit. If a zero-limit IOTLB still reaches the common<br /> helper, treat it as a configuration error and return -EINVAL.<br /> <br /> I found this bug myself, though the patch was written with AI assistance.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()<br /> <br /> reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto<br /> the ehash chain, drops the bucket lock, and only afterwards sets<br /> rsk_refcnt to 3.<br /> <br /> Lockless readers such as __inet_lookup_established() handle this with<br /> refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain<br /> sock_hold() while holding the bucket lock, on the assumption that the<br /> lock guarantees sk_refcnt &gt; 0. That assumption does not hold for<br /> request_sock:<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> tcp_conn_request()<br /> reqsk_queue_hash_req()<br /> inet_ehash_insert(req)<br /> spin_lock(bucket)<br /> __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0<br /> spin_unlock(bucket)<br /> bpf_iter_tcp_established_batch()<br /> spin_lock(bucket)<br /> sock_hold(req) rsk_refcnt, 3) // clobbers saturated value<br /> <br /> which surfaces as:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1<br /> Call Trace:<br /> bpf_iter_tcp_established_batch+0x14e/0x170<br /> bpf_iter_tcp_batch+0x53/0x200<br /> bpf_iter_tcp_seq_next+0x27/0x70<br /> bpf_seq_read+0x107/0x410<br /> vfs_read+0xb9/0x380<br /> <br /> The iterator&amp;#39;s stolen reference is lost when the publishing CPU&amp;#39;s<br /> refcount_set() overwrites the count, leaving the socket one reference<br /> short. When the last legitimate owner drops its reference the reqsk is<br /> freed while still reachable, leading to use-after-free.<br /> <br /> This reproduces in seconds with tcp_syncookies=0, a handful of threads<br /> doing connect()/close() to a local listener while others read an<br /> iter/tcp link in a tight loop.<br /> <br /> Use refcount_inc_not_zero() and skip the socket on failure. A skipped<br /> socket is still part of the bucket, so keep counting it in expected.<br /> The reallocations are sized from expected, and a request sock whose<br /> refcount gets published while the lock is held across the last realloc<br /> must already have room.<br /> <br /> A skipped socket is counted in expected but never batched, so end_sk<br /> can be short of expected on a batch that is actually complete. Decide<br /> completeness by whether the walk left any socket behind instead. The<br /> WARN after the locked realloc checks the same, replacing an<br /> end_sk == expected check that could not hold on that path since<br /> commit cdec67a489d4 ("bpf: tcp: Make sure iter-&gt;batch always<br /> contains a full bucket snapshot").<br /> <br /> If every matching socket in a bucket is mid-init (refcount 0), end_sk<br /> stays 0. Advance to the next bucket rather than returning a batch entry<br /> that was never filled this round.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix netns reference imbalance in conntrack kfuncs<br /> <br /> The opts argument of the BPF conntrack kfuncs can point to a shared<br /> map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read<br /> opts-&gt;netns_id separately when acquiring and releasing the network<br /> namespace reference.<br /> <br /> The reference imbalance can occur as follows:<br /> <br /> CPU 0 CPU 1<br /> read opts-&gt;netns_id (-1)<br /> skip get_net_ns_by_id()<br /> write opts-&gt;netns_id (id)<br /> read opts-&gt;netns_id (id)<br /> put_net(net) /* no matching get */<br /> <br /> The reverse transition leaks the reference. Repeating the unmatched put<br /> can destroy a live namespace and crash later users.<br /> <br /> The kernel reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]<br /> RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700<br /> Call Trace:<br /> __sys_bpf+0x1662/0x50c0<br /> __x64_sys_bpf+0x73/0xb0<br /> do_syscall_64+0xf9/0x540<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Snapshot every input field of opts with READ_ONCE() before validating or<br /> using it. The netns_id snapshot keeps the namespace get/put pair<br /> balanced, while the other snapshots keep the remaining options from<br /> changing partway through an invocation. The individual reads can still<br /> observe an inconsistent combination during a concurrent update, but each<br /> selected field value remains stable for that invocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()<br /> <br /> In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears<br /> VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM<br /> object and then calls madvise(MADV_DONTNEED), the PTEs will be<br /> successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP).<br /> <br /> When userspace subsequently accesses the memory, drm_gem_shmem_fault()<br /> handles the page fault and attempts to map the backing shmem page via<br /> vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing<br /> shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA<br /> now has VM_MIXEDMAP set, won&amp;#39;t this predictably trigger the explicit<br /> assertion BUG_ON((vma-&gt;vm_flags &amp; VM_MIXEDMAP) &amp;&amp; pfn_valid(pfn))<br /> <br /> Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages()<br /> pre-population with the handle_mm_fault() loop that was already used for<br /> the import (dma-buf) path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: fw_tracer, return NULL on create error<br /> <br /> Tracer creation can fail by returning either NULL or ERR_PTR.<br /> The return value is stored without a check on the device, and users<br /> treat ERR_PTR and NULL the same way.<br /> This also causes a crash in the core dump logic, which is missing the<br /> ERR_PTR check and ends up dereferencing it, as shown in the trace below.<br /> <br /> Switch tracer creation to return NULL on failure only, so callers only<br /> need a single NULL check.<br /> <br /> Internal error: Oops: 0000000096000006 [#1] SMP<br /> Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core<br /> CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none)<br /> Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core]<br /> pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core]<br /> lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core]<br /> sp : ffff800081cf3c40<br /> x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000<br /> x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05<br /> x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000<br /> x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0<br /> x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac<br /> x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650<br /> x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8<br /> x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030<br /> x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e<br /> Call trace:<br /> mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P)<br /> mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core]<br /> devlink_health_do_dump+0x9c/0x160<br /> devlink_health_report+0x1c0/0x288<br /> mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core]<br /> process_one_work+0x15c/0x3d8<br /> worker_thread+0x18c/0x320<br /> kthread+0x148/0x228<br /> ret_from_fork+0x10/0x20<br /> Code: b9400000 5ac00800 7a401800 540003ca (3940a260)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception<br /> SMP: stopping secondary CPUs<br /> Kernel Offset: disabled<br /> CPU features: 0x000000,00078031,75fce5a1,35fffe67<br /> Memory Limit: none<br /> ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---