Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix kernel panic during drive powercycle test<br /> <br /> While looping over shost&amp;#39;s sdev list it is possible that one<br /> of the drives is getting removed and its sas_target object is<br /> freed but its sdev object remains intact.<br /> <br /> Consequently, a kernel panic can occur while the driver is trying to access<br /> the sas_address field of sas_target object without also checking the<br /> sas_target object for NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> proc/vmcore: fix clearing user buffer by properly using clear_user()<br /> <br /> To clear a user buffer we cannot simply use memset, we have to use<br /> clear_user(). With a virtio-mem device that registers a vmcore_cb and<br /> has some logically unplugged memory inside an added Linux memory block,<br /> I can easily trigger a BUG by copying the vmcore via "cp":<br /> <br /> systemd[1]: Starting Kdump Vmcore Save Service...<br /> kdump[420]: Kdump is using the default log level(3).<br /> kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/<br /> kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/<br /> kdump[465]: saving vmcore-dmesg.txt complete<br /> kdump[467]: saving vmcore<br /> BUG: unable to handle page fault for address: 00007f2374e01000<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0003) - permissions violation<br /> PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867<br /> Oops: 0003 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86<br /> Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81<br /> RSP: 0018:ffffc9000073be08 EFLAGS: 00010212<br /> RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000<br /> RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008<br /> RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50<br /> R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000<br /> R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8<br /> FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0<br /> Call Trace:<br /> read_vmcore+0x236/0x2c0<br /> proc_reg_read+0x55/0xa0<br /> vfs_read+0x95/0x190<br /> ksys_read+0x4f/0xc0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access<br /> Prevention (SMAP)", which is used to detect wrong access from the kernel<br /> to user buffers like this: SMAP triggers a permissions violation on<br /> wrong access. In the x86-64 variant of clear_user(), SMAP is properly<br /> handled via clac()+stac().<br /> <br /> To fix, properly use clear_user() when we&amp;#39;re dealing with a user buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/32: Fix hardlockup on vmap stack overflow<br /> <br /> Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not<br /> activate MMU before reading task struct") a vmap stack overflow<br /> results in a hard lockup. This is because emergency_ctx is still<br /> addressed with its virtual address allthough data MMU is not active<br /> anymore at that time.<br /> <br /> Fix it by using a physical address instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()<br /> <br /> For avoiding to slow down queue destroy, we don&amp;#39;t call<br /> blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to<br /> cancel dispatch work in blk_release_queue().<br /> <br /> However, this way has caused kernel oops[1], reported by Changhui. The log<br /> shows that scsi_device can be freed before running blk_release_queue(),<br /> which is expected too since scsi_device is released after the scsi disk<br /> is closed and the scsi_device is removed.<br /> <br /> Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()<br /> and disk_release():<br /> <br /> 1) when disk_release() is run, the disk has been closed, and any sync<br /> dispatch activities have been done, so canceling dispatch work is enough to<br /> quiesce filesystem I/O dispatch activity.<br /> <br /> 2) in blk_cleanup_queue(), we only focus on passthrough request, and<br /> passthrough request is always explicitly allocated &amp; freed by<br /> its caller, so once queue is frozen, all sync dispatch activity<br /> for passthrough request has been done, then it is enough to just cancel<br /> dispatch work for avoiding any dispatch activity.<br /> <br /> [1] kernel panic log<br /> [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300<br /> [12622.777186] #PF: supervisor read access in kernel mode<br /> [12622.782918] #PF: error_code(0x0000) - not-present page<br /> [12622.788649] PGD 0 P4D 0<br /> [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1<br /> [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015<br /> [12622.813321] Workqueue: kblockd blk_mq_run_work_fn<br /> [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190<br /> [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58<br /> [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202<br /> [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004<br /> [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030<br /> [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334<br /> [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000<br /> [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030<br /> [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000<br /> [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0<br /> [12622.913328] Call Trace:<br /> [12622.916055] <br /> [12622.918394] scsi_mq_get_budget+0x1a/0x110<br /> [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320<br /> [12622.928404] ? pick_next_task_fair+0x39/0x390<br /> [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140<br /> [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60<br /> [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0<br /> [12622.949593] process_one_work+0x1e8/0x3c0<br /> [12622.954059] worker_thread+0x50/0x3b0<br /> [12622.958144] ? rescuer_thread+0x370/0x370<br /> [12622.962616] kthread+0x158/0x180<br /> [12622.966218] ? set_kthread_struct+0x40/0x40<br /> [12622.970884] ret_from_fork+0x22/0x30<br /> [12622.974875] <br /> [12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_w<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/scs: Reset task stack state in bringup_cpu()<br /> <br /> To hot unplug a CPU, the idle task on that CPU calls a few layers of C<br /> code before finally leaving the kernel. When KASAN is in use, poisoned<br /> shadow is left around for each of the active stack frames, and when<br /> shadow call stacks are in use. When shadow call stacks (SCS) are in use<br /> the task&amp;#39;s saved SCS SP is left pointing at an arbitrary point within<br /> the task&amp;#39;s shadow call stack.<br /> <br /> When a CPU is offlined than onlined back into the kernel, this stale<br /> state can adversely affect execution. Stale KASAN shadow can alias new<br /> stackframes and result in bogus KASAN warnings. A stale SCS SP is<br /> effectively a memory leak, and prevents a portion of the shadow call<br /> stack being used. Across a number of hotplug cycles the idle task&amp;#39;s<br /> entire shadow call stack can become unusable.<br /> <br /> We previously fixed the KASAN issue in commit:<br /> <br /> e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")<br /> <br /> ... by removing any stale KASAN stack poison immediately prior to<br /> onlining a CPU.<br /> <br /> Subsequently in commit:<br /> <br /> f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")<br /> <br /> ... the refactoring left the KASAN and SCS cleanup in one-time idle<br /> thread initialization code rather than something invoked prior to each<br /> CPU being onlined, breaking both as above.<br /> <br /> We fixed SCS (but not KASAN) in commit:<br /> <br /> 63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")<br /> <br /> ... but as this runs in the context of the idle task being offlined it&amp;#39;s<br /> potentially fragile.<br /> <br /> To fix these consistently and more robustly, reset the SCS SP and KASAN<br /> shadow of a CPU&amp;#39;s idle task immediately before we online that CPU in<br /> bringup_cpu(). This ensures the idle task always has a consistent state<br /> when it is running, and removes the need to so so when exiting an idle<br /> task.<br /> <br /> Whenever any thread is created, dup_task_struct() will give the task a<br /> stack which is free of KASAN shadow, and initialize the task&amp;#39;s SCS SP,<br /> so there&amp;#39;s no need to specially initialize either for idle thread within<br /> init_idle(), as this was only necessary to handle hotplug cycles.<br /> <br /> I&amp;#39;ve tested this on arm64 with:<br /> <br /> * gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK<br /> * clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK<br /> <br /> ... offlining and onlining CPUS with:<br /> <br /> | while true; do<br /> | for C in /sys/devices/system/cpu/cpu*/online; do<br /> | echo 0 &gt; $C;<br /> | echo 1 &gt; $C;<br /> | done<br /> | done

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa_sim: avoid putting an uninitialized iova_domain<br /> <br /> The system will crash if we put an uninitialized iova_domain, this<br /> could happen when an error occurs before initializing the iova_domain<br /> in vdpasim_create().<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0<br /> ...<br /> Call Trace:<br /> <br /> put_iova_domain+0x29/0x220<br /> vdpasim_free+0xd1/0x120 [vdpa_sim]<br /> vdpa_release_dev+0x21/0x40 [vdpa]<br /> device_release+0x33/0x90<br /> kobject_release+0x63/0x160<br /> vdpasim_create+0x127/0x2a0 [vdpa_sim]<br /> vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net]<br /> vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa]<br /> genl_family_rcv_msg_doit+0x112/0x140<br /> genl_rcv_msg+0xdf/0x1d0<br /> ...<br /> <br /> So we must make sure the iova_domain is already initialized before<br /> put it.<br /> <br /> In addition, we may get the following warning in this case:<br /> WARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70<br /> <br /> So we must make sure the iova_cache_put() is invoked only if the<br /> iova_cache_get() is already invoked. Let&amp;#39;s fix it together.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: vlan: fix underflow for the real_dev refcnt<br /> <br /> Inject error before dev_hold(real_dev) in register_vlan_dev(),<br /> and execute the following testcase:<br /> <br /> ip link add dev dummy1 type dummy<br /> ip link add name dummy1.100 link dummy1 type vlan id 100<br /> ip link del dev dummy1<br /> <br /> When the dummy netdevice is removed, we will get a WARNING as following:<br /> <br /> =======================================================================<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0<br /> <br /> and an endless loop of:<br /> <br /> =======================================================================<br /> unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824<br /> <br /> That is because dev_put(real_dev) in vlan_dev_free() be called without<br /> dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev<br /> underflow.<br /> <br /> Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of<br /> ndo_init(). That makes dev_hold() and dev_put() for vlan&amp;#39;s real_dev<br /> symmetrical.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()<br /> <br /> ethtool_set_coalesce() now uses both the .get_coalesce() and<br /> .set_coalesce() callbacks. But the check for their availability is<br /> buggy, so changing the coalesce settings on a device where the driver<br /> provides only _one_ of the callbacks results in a NULL pointer<br /> dereference instead of an -EOPNOTSUPP.<br /> <br /> Fix the condition so that the availability of both callbacks is<br /> ensured. This also matches the netlink code.<br /> <br /> Note that reproducing this requires some effort - it only affects the<br /> legacy ioctl path, and needs a specific combination of driver options:<br /> - have .get_coalesce() and .coalesce_supported but no<br /> .set_coalesce(), or<br /> - have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn&amp;#39;t<br /> cause the crash as it first attempts to call ethtool_get_coalesce()<br /> and bails out on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_ets: don&amp;#39;t peek at classes beyond &amp;#39;nbands&amp;#39;<br /> <br /> when the number of DRR classes decreases, the round-robin active list can<br /> contain elements that have already been freed in ets_qdisc_change(). As a<br /> consequence, it&amp;#39;s possible to see a NULL dereference crash, caused by the<br /> attempt to call cl-&gt;qdisc-&gt;ops-&gt;peek(cl-&gt;qdisc) when cl-&gt;qdisc is NULL:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets]<br /> Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d<br /> RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287<br /> RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000<br /> RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0<br /> R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100<br /> FS: 00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> qdisc_peek_dequeued+0x29/0x70 [sch_ets]<br /> tbf_dequeue+0x22/0x260 [sch_tbf]<br /> __qdisc_run+0x7f/0x630<br /> net_tx_action+0x290/0x4c0<br /> __do_softirq+0xee/0x4f8<br /> irq_exit_rcu+0xf4/0x130<br /> sysvec_apic_timer_interrupt+0x52/0xc0<br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> RIP: 0033:0x7f2aa7fc9ad4<br /> Code: b9 ff ff 48 8b 54 24 18 48 83 c4 08 48 89 ee 48 89 df 5b 5d e9 ed fc ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 83 ec 10 48 8b 05 10 64 33 00 48 8b 00 48 85 c0 0f 85 84 00<br /> RSP: 002b:00007ffe5d33fab8 EFLAGS: 00000202<br /> RAX: 0000000000000002 RBX: 0000561f72c31460 RCX: 0000561f72c31720<br /> RDX: 0000000000000002 RSI: 0000561f72c31722 RDI: 0000561f72c31720<br /> RBP: 000000000000002a R08: 00007ffe5d33fa40 R09: 0000000000000014<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000561f7187e380<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000561f72c31460<br /> <br /> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt intel_rapl_msr iTCO_vendor_support intel_rapl_common joydev virtio_balloon lpc_ich i2c_i801 i2c_smbus pcspkr ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel serio_raw libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod<br /> CR2: 0000000000000018<br /> <br /> Ensuring that &amp;#39;alist&amp;#39; was never zeroed [1] was not sufficient, we need to<br /> remove from the active list those elements that are no more SP nor DRR.<br /> <br /> [1] https://lore.kernel.org/netdev/60d274838bf09777f0371253416e8af71360bc08.1633609148.git.dcaratti@redhat.com/<br /> <br /> v3: fix race between ets_qdisc_change() and ets_qdisc_dequeue() delisting<br /> DRR classes beyond &amp;#39;nbands&amp;#39; in ets_qdisc_change() with the qdisc lock<br /> acquired, thanks to Cong Wang.<br /> <br /> v2: when a NULL qdisc is found in the DRR active list, try to dequeue skb<br /> from the next list item.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Disable Tx queues when reconfiguring the interface<br /> <br /> The Tx queues were not disabled in situations where the driver needed to<br /> stop the interface to apply a new configuration. This could result in a<br /> kernel panic when doing any of the 3 following actions:<br /> * reconfiguring the number of queues (ethtool -L)<br /> * reconfiguring the size of the ring buffers (ethtool -G)<br /> * installing/removing an XDP program (ip l set dev ethX xdp)<br /> <br /> Prevent the panic by making sure netif_tx_disable is called when stopping<br /> an interface.<br /> <br /> Without this patch, the following kernel panic can be observed when doing<br /> any of the actions above:<br /> <br /> Unable to handle kernel paging request at virtual address ffff80001238d040<br /> [....]<br /> Call trace:<br /> dwmac4_set_addr+0x8/0x10<br /> dev_hard_start_xmit+0xe4/0x1ac<br /> sch_direct_xmit+0xe8/0x39c<br /> __dev_queue_xmit+0x3ec/0xaf0<br /> dev_queue_xmit+0x14/0x20<br /> [...]<br /> [ end trace 0000000000000002 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()<br /> <br /> Coverity reports a possible NULL dereferencing problem:<br /> <br /> in smc_vlan_by_tcpsk():<br /> 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).<br /> 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.<br /> 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &amp;lower);<br /> CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)<br /> 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.<br /> 1624 if (is_vlan_dev(ndev)) {<br /> <br /> Remove the manual implementation and use netdev_walk_all_lower_dev() to<br /> iterate over the lower devices. While on it remove an obsolete function<br /> parameter comment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum: Protect driver from buggy firmware<br /> <br /> When processing port up/down events generated by the device&amp;#39;s firmware,<br /> the driver protects itself from events reported for non-existent local<br /> ports, but not the CPU port (local port 0), which exists, but lacks a<br /> netdev.<br /> <br /> This can result in a NULL pointer dereference when calling<br /> netif_carrier_{on,off}().<br /> <br /> Fix this by bailing early when processing an event reported for the CPU<br /> port. Problem was only observed when running on top of a buggy emulator.