Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix qi_batch NULL pointer with nested parent domain<br /> <br /> The qi_batch is allocated when assigning cache tag for a domain. While<br /> for nested parent domain, it is missed. Hence, when trying to map pages<br /> to the nested parent, NULL dereference occurred. Also, there is potential<br /> memleak since there is no lock around domain-&gt;qi_batch allocation.<br /> <br /> To solve it, add a helper for qi_batch allocation, and call it in both<br /> the __cache_tag_assign_domain() and __cache_tag_assign_parent_domain().<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000200<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 8104795067 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 223 UID: 0 PID: 4357 Comm: qemu-system-x86 Not tainted 6.13.0-rc1-00028-g4b50c3c3b998-dirty #2632<br /> Call Trace:<br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x80/0x150<br /> ? do_user_addr_fault+0x63/0x7b0<br /> ? exc_page_fault+0x7c/0x220<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? cache_tag_flush_range_np+0x13c/0x260<br /> intel_iommu_iotlb_sync_map+0x1a/0x30<br /> iommu_map+0x61/0xf0<br /> batch_to_domain+0x188/0x250<br /> iopt_area_fill_domains+0x125/0x320<br /> ? rcu_is_watching+0x11/0x50<br /> iopt_map_pages+0x63/0x100<br /> iopt_map_common.isra.0+0xa7/0x190<br /> iopt_map_user_pages+0x6a/0x80<br /> iommufd_ioas_map+0xcd/0x1d0<br /> iommufd_fops_ioctl+0x118/0x1c0<br /> __x64_sys_ioctl+0x93/0xc0<br /> do_syscall_64+0x71/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix NULL pointer dereference in capture_engine<br /> <br /> When the intel_context structure contains NULL,<br /> it raises a NULL pointer dereference error in drm_info().<br /> <br /> (cherry picked from commit 754302a5bc1bd8fd3b7d85c168b0a1af6d4bba4d)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Dereference null return value<br /> <br /> In the function pqm_uninit there is a call-assignment of "pdd =<br /> kfd_get_process_device_data" which could be null, and this value was<br /> later dereferenced without checking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog<br /> <br /> Syzbot reported [1] crash that happens for following tracing scenario:<br /> <br /> - create tracepoint perf event with attr.inherit=1, attach it to the<br /> process and set bpf program to it<br /> - attached process forks -&gt; chid creates inherited event<br /> <br /> the new child event shares the parent&amp;#39;s bpf program and tp_event<br /> (hence prog_array) which is global for tracepoint<br /> <br /> - exit both process and its child -&gt; release both events<br /> - first perf_event_detach_bpf_prog call will release tp_event-&gt;prog_array<br /> and second perf_event_detach_bpf_prog will crash, because<br /> tp_event-&gt;prog_array is NULL<br /> <br /> The fix makes sure the perf_event_detach_bpf_prog checks prog_array<br /> is valid before it tries to remove the bpf program from it.<br /> <br /> [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: fix NL80211_ATTR_MLO_LINK_ID off-by-one<br /> <br /> Since the netlink attribute range validation provides inclusive<br /> checking, the *max* of attribute NL80211_ATTR_MLO_LINK_ID should be<br /> IEEE80211_MLD_MAX_NUM_LINKS - 1 otherwise causing an off-by-one.<br /> <br /> One crash stack for demonstration:<br /> ==================================================================<br /> BUG: KASAN: wild-memory-access in ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939<br /> Read of size 6 at addr 001102080000000c by task fuzzer.386/9508<br /> <br /> CPU: 1 PID: 9508 Comm: syz.1.386 Not tainted 6.1.70 #2<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106<br /> print_report+0xe0/0x750 mm/kasan/report.c:398<br /> kasan_report+0x139/0x170 mm/kasan/report.c:495<br /> kasan_check_range+0x287/0x290 mm/kasan/generic.c:189<br /> memcpy+0x25/0x60 mm/kasan/shadow.c:65<br /> ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939<br /> rdev_tx_control_port net/wireless/rdev-ops.h:761 [inline]<br /> nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453<br /> genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756<br /> genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]<br /> genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850<br /> netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508<br /> genl_rcv+0x24/0x40 net/netlink/genetlink.c:861<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]<br /> netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352<br /> netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874<br /> sock_sendmsg_nosec net/socket.c:716 [inline]<br /> __sock_sendmsg net/socket.c:728 [inline]<br /> ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499<br /> ___sys_sendmsg+0x21c/0x290 net/socket.c:2553<br /> __sys_sendmsg net/socket.c:2582 [inline]<br /> __do_sys_sendmsg net/socket.c:2591 [inline]<br /> __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Update the policy to ensure correct validation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Remove cache tags before disabling ATS<br /> <br /> The current implementation removes cache tags after disabling ATS,<br /> leading to potential memory leaks and kernel crashes. Specifically,<br /> CACHE_TAG_DEVTLB type cache tags may still remain in the list even<br /> after the domain is freed, causing a use-after-free condition.<br /> <br /> This issue really shows up when multiple VFs from different PFs<br /> passed through to a single user-space process via vfio-pci. In such<br /> cases, the kernel may crash with kernel messages like:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000014<br /> PGD 19036a067 P4D 1940a3067 PUD 136c9b067 PMD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 74 UID: 0 PID: 3183 Comm: testCli Not tainted 6.11.9 #2<br /> RIP: 0010:cache_tag_flush_range+0x9b/0x250<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x60<br /> ? page_fault_oops+0x163/0x590<br /> ? exc_page_fault+0x72/0x190<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? cache_tag_flush_range+0x9b/0x250<br /> ? cache_tag_flush_range+0x5d/0x250<br /> intel_iommu_tlb_sync+0x29/0x40<br /> intel_iommu_unmap_pages+0xfe/0x160<br /> __iommu_unmap+0xd8/0x1a0<br /> vfio_unmap_unpin+0x182/0x340 [vfio_iommu_type1]<br /> vfio_remove_dma+0x2a/0xb0 [vfio_iommu_type1]<br /> vfio_iommu_type1_ioctl+0xafa/0x18e0 [vfio_iommu_type1]<br /> <br /> Move cache_tag_unassign_domain() before iommu_disable_pci_caps() to fix<br /> it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix race between element replace and close()<br /> <br /> Element replace (with a socket different from the one stored) may race<br /> with socket&amp;#39;s close() link popping &amp; unlinking. __sock_map_delete()<br /> unconditionally unrefs the (wrong) element:<br /> <br /> // set map[0] = s0<br /> map_update_elem(map, 0, s0)<br /> <br /> // drop fd of s0<br /> close(s0)<br /> sock_map_close()<br /> lock_sock(sk) (s0!)<br /> sock_map_remove_links(sk)<br /> link = sk_psock_link_pop()<br /> sock_map_unlink(sk, link)<br /> sock_map_delete_from_link<br /> // replace map[0] with s1<br /> map_update_elem(map, 0, s1)<br /> sock_map_update_elem<br /> (s1!) lock_sock(sk)<br /> sock_map_update_common<br /> psock = sk_psock(sk)<br /> spin_lock(&amp;stab-&gt;lock)<br /> osk = stab-&gt;sks[idx]<br /> sock_map_add_link(..., &amp;stab-&gt;sks[idx])<br /> sock_map_unref(osk, &amp;stab-&gt;sks[idx])<br /> psock = sk_psock(osk)<br /> sk_psock_put(sk, psock)<br /> if (refcount_dec_and_test(&amp;psock))<br /> sk_psock_drop(sk, psock)<br /> spin_unlock(&amp;stab-&gt;lock)<br /> unlock_sock(sk)<br /> __sock_map_delete<br /> spin_lock(&amp;stab-&gt;lock)<br /> sk = *psk // s1 replaced s0; sk == s1<br /> if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch<br /> sk = xchg(psk, NULL)<br /> if (sk)<br /> sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle<br /> psock = sk_psock(sk)<br /> sk_psock_put(sk, psock)<br /> if (refcount_dec_and_test())<br /> sk_psock_drop(sk, psock)<br /> spin_unlock(&amp;stab-&gt;lock)<br /> release_sock(sk)<br /> <br /> Then close(map) enqueues bpf_map_free_deferred, which finally calls<br /> sock_map_free(). This results in some refcount_t warnings along with<br /> a KASAN splat [1].<br /> <br /> Fix __sock_map_delete(), do not allow sock_map_unref() on elements that<br /> may have been replaced.<br /> <br /> [1]:<br /> BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330<br /> Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063<br /> <br /> CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014<br /> Workqueue: events_unbound bpf_map_free_deferred<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x68/0x90<br /> print_report+0x174/0x4f6<br /> kasan_report+0xb9/0x190<br /> kasan_check_range+0x10f/0x1e0<br /> sock_map_free+0x10e/0x330<br /> bpf_map_free_deferred+0x173/0x320<br /> process_one_work+0x846/0x1420<br /> worker_thread+0x5b3/0xf80<br /> kthread+0x29e/0x360<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 1202:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_save_track+0x10/0x30<br /> __kasan_slab_alloc+0x85/0x90<br /> kmem_cache_alloc_noprof+0x131/0x450<br /> sk_prot_alloc+0x5b/0x220<br /> sk_alloc+0x2c/0x870<br /> unix_create1+0x88/0x8a0<br /> unix_create+0xc5/0x180<br /> __sock_create+0x241/0x650<br /> __sys_socketpair+0x1ce/0x420<br /> __x64_sys_socketpair+0x92/0x100<br /> do_syscall_64+0x93/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 46:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x60<br /> __kasan_slab_free+0x4b/0x70<br /> kmem_cache_free+0x1a1/0x590<br /> __sk_destruct+0x388/0x5a0<br /> sk_psock_destroy+0x73e/0xa50<br /> process_one_work+0x846/0x1420<br /> worker_thread+0x5b3/0xf80<br /> kthread+0x29e/0x360<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> The bu<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl<br /> <br /> Fix an issue detected by syzbot with KASAN:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/<br /> core.c:416 [inline]<br /> BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0<br /> drivers/acpi/nfit/core.c:459<br /> <br /> The issue occurs in cmd_to_func when the call_pkg-&gt;nd_reserved2<br /> array is accessed without verifying that call_pkg points to a buffer<br /> that is appropriately sized as a struct nd_cmd_pkg. This can lead<br /> to out-of-bounds access and undefined behavior if the buffer does not<br /> have sufficient space.<br /> <br /> To address this, a check was added in acpi_nfit_ctl() to ensure that<br /> buf is not NULL and that buf_len is less than sizeof(*call_pkg)<br /> before accessing it. This ensures safe access to the members of<br /> call_pkg, including the nd_reserved2 array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips<br /> <br /> The 5760X (P7) chip&amp;#39;s HW GRO/LRO interface is very similar to that of<br /> the previous generation (5750X or P5). However, the aggregation ID<br /> fields in the completion structures on P7 have been redefined from<br /> 16 bits to 12 bits. The freed up 4 bits are redefined for part of the<br /> metadata such as the VLAN ID. The aggregation ID mask was not modified<br /> when adding support for P7 chips. Including the extra 4 bits for the<br /> aggregation ID can potentially cause the driver to store or fetch the<br /> packet header of GRO/LRO packets in the wrong TPA buffer. It may hit<br /> the BUG() condition in __skb_pull() because the SKB contains no valid<br /> packet header:<br /> <br /> kernel BUG at include/linux/skbuff.h:2766!<br /> Oops: invalid opcode: 0000 1 PREEMPT SMP NOPTI<br /> CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G OE 6.12.0-rc2+ #7<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022<br /> RIP: 0010:eth_type_trans+0xda/0x140<br /> Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48<br /> RSP: 0018:ff615003803fcc28 EFLAGS: 00010283<br /> RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040<br /> RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000<br /> RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001<br /> R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0<br /> R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000<br /> FS: 0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? die+0x33/0x90<br /> ? do_trap+0xd9/0x100<br /> ? eth_type_trans+0xda/0x140<br /> ? do_error_trap+0x65/0x80<br /> ? eth_type_trans+0xda/0x140<br /> ? exc_invalid_op+0x4e/0x70<br /> ? eth_type_trans+0xda/0x140<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? eth_type_trans+0xda/0x140<br /> bnxt_tpa_end+0x10b/0x6b0 [bnxt_en]<br /> ? bnxt_tpa_start+0x195/0x320 [bnxt_en]<br /> bnxt_rx_pkt+0x902/0xd90 [bnxt_en]<br /> ? __bnxt_tx_int.constprop.0+0x89/0x300 [bnxt_en]<br /> ? kmem_cache_free+0x343/0x440<br /> ? __bnxt_tx_int.constprop.0+0x24f/0x300 [bnxt_en]<br /> __bnxt_poll_work+0x193/0x370 [bnxt_en]<br /> bnxt_poll_p5+0x9a/0x300 [bnxt_en]<br /> ? try_to_wake_up+0x209/0x670<br /> __napi_poll+0x29/0x1b0<br /> <br /> Fix it by redefining the aggregation ID mask for P5_PLUS chips to be<br /> 12 bits. This will work because the maximum aggregation ID is less<br /> than 4096 on all P5_PLUS chips.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: control: Avoid WARN() for symlink errors<br /> <br /> Using WARN() for showing the error of symlink creations don&amp;#39;t give<br /> more information than telling that something goes wrong, since the<br /> usual code path is a lregister callback from each control element<br /> creation. More badly, the use of WARN() rather confuses fuzzer as if<br /> it were serious issues.<br /> <br /> This patch downgrades the warning messages to use the normal dev_err()<br /> instead of WARN(). For making it clearer, add the function name to<br /> the prefix, too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: lapb: increase LAPB_HEADER_LEN<br /> <br /> It is unclear if net/lapb code is supposed to be ready for 8021q.<br /> <br /> We can at least avoid crashes like the following :<br /> <br /> skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:206 !<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024<br /> RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]<br /> RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216<br /> Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3<br /> RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282<br /> RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600<br /> RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000<br /> RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60<br /> R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140<br /> R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016<br /> FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> skb_push+0xe5/0x100 net/core/skbuff.c:2636<br /> nr_header+0x36/0x320 net/netrom/nr_dev.c:69<br /> dev_hard_header include/linux/netdevice.h:3148 [inline]<br /> vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83<br /> dev_hard_header include/linux/netdevice.h:3148 [inline]<br /> lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257<br /> lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447<br /> lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149<br /> lapb_establish_data_link+0x84/0xd0<br /> lapb_device_event+0x4e0/0x670<br /> notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93<br /> __dev_notify_flags+0x207/0x400<br /> dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922<br /> devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188<br /> inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003<br /> sock_do_ioctl+0x158/0x460 net/socket.c:1227<br /> sock_ioctl+0x626/0x8e0 net/socket.c:1346<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating<br /> <br /> The usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is<br /> not safe since for the most part entries fetched this way shall be<br /> treated as rcu_dereference:<br /> <br /> Note that the value returned by rcu_dereference() is valid<br /> only within the enclosing RCU read-side critical section [1]_.<br /> For example, the following is **not** legal::<br /> <br /> rcu_read_lock();<br /> p = rcu_dereference(head.next);<br /> rcu_read_unlock();<br /> x = p-&gt;address; /* BUG!!! */<br /> rcu_read_lock();<br /> y = p-&gt;data; /* BUG!!! */<br /> rcu_read_unlock();