Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix GEM free for imported dma-bufs<br /> <br /> Imported dma-bufs also have obj-&gt;resv != &amp;obj-&gt;_resv. So we should<br /> check both this condition in addition to flags for handling the<br /> _NO_SHARE case.<br /> <br /> Fixes this splat that was reported with IRIS video playback:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 3 PID: 2040 at drivers/gpu/drm/msm/msm_gem.c:1127 msm_gem_free_object+0x1f8/0x264 [msm]<br /> CPU: 3 UID: 1000 PID: 2040 Comm: .gnome-shell-wr Not tainted 6.17.0-rc7 #1 PREEMPT<br /> pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : msm_gem_free_object+0x1f8/0x264 [msm]<br /> lr : msm_gem_free_object+0x138/0x264 [msm]<br /> sp : ffff800092a1bb30<br /> x29: ffff800092a1bb80 x28: ffff800092a1bce8 x27: ffffbc702dbdbe08<br /> x26: 0000000000000008 x25: 0000000000000009 x24: 00000000000000a6<br /> x23: ffff00083c72f850 x22: ffff00083c72f868 x21: ffff00087e69f200<br /> x20: ffff00087e69f330 x19: ffff00084d157ae0 x18: 0000000000000000<br /> x17: 0000000000000000 x16: ffffbc704bd46b80 x15: 0000ffffd0959540<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffffbc702e6cdb48 x10: 0000000000000000 x9 : 000000000000003f<br /> x8 : ffff800092a1ba90 x7 : 0000000000000000 x6 : 0000000000000020<br /> x5 : ffffbc704bd46c40 x4 : fffffdffe102cf60 x3 : 0000000000400032<br /> x2 : 0000000000020000 x1 : ffff00087e6978e8 x0 : ffff00087e6977e8<br /> Call trace:<br /> msm_gem_free_object+0x1f8/0x264 [msm] (P)<br /> drm_gem_object_free+0x1c/0x30 [drm]<br /> drm_gem_object_handle_put_unlocked+0x138/0x150 [drm]<br /> drm_gem_object_release_handle+0x5c/0xcc [drm]<br /> drm_gem_handle_delete+0x68/0xbc [drm]<br /> drm_gem_close_ioctl+0x34/0x40 [drm]<br /> drm_ioctl_kernel+0xc0/0x130 [drm]<br /> drm_ioctl+0x360/0x4e0 [drm]<br /> __arm64_sys_ioctl+0xac/0x104<br /> invoke_syscall+0x48/0x104<br /> el0_svc_common.constprop.0+0x40/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xec<br /> el0t_64_sync_handler+0xa0/0xe4<br /> el0t_64_sync+0x198/0x19c<br /> ---[ end trace 0000000000000000 ]---<br /> ------------[ cut here ]------------<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/676273/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()<br /> <br /> kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws<br /> remains NULL while ectx.ws_size is set, leading to a potential NULL<br /> pointer dereference in atom_get_src_int() when accessing WS entries.<br /> <br /> Return -ENOMEM on allocation failure to avoid the NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp_tunnel: use netdev_warn() instead of netdev_WARN()<br /> <br /> netdev_WARN() uses WARN/WARN_ON to print a backtrace along with<br /> file and line information. In this case, udp_tunnel_nic_register()<br /> returning an error is just a failed operation, not a kernel bug.<br /> <br /> udp_tunnel_nic_register() can fail due to a memory allocation<br /> failure (kzalloc() or udp_tunnel_nic_alloc()).<br /> This is a normal runtime error and not a kernel bug.<br /> <br /> Replace netdev_WARN() with netdev_warn() accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup<br /> <br /> Raw IP packets have no MAC header, leaving skb-&gt;mac_header uninitialized.<br /> This can trigger kernel panics on ARM64 when xfrm or other subsystems<br /> access the offset due to strict alignment checks.<br /> <br /> Initialize the MAC header to prevent such crashes.<br /> <br /> This can trigger kernel panics on ARM when running IPsec over the<br /> qmimux0 interface.<br /> <br /> Example trace:<br /> <br /> Internal error: Oops: 000000009600004f [#1] SMP<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1<br /> Hardware name: LS1028A RDB Board (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : xfrm_input+0xde8/0x1318<br /> lr : xfrm_input+0x61c/0x1318<br /> sp : ffff800080003b20<br /> Call trace:<br /> xfrm_input+0xde8/0x1318<br /> xfrm6_rcv+0x38/0x44<br /> xfrm6_esp_rcv+0x48/0xa8<br /> ip6_protocol_deliver_rcu+0x94/0x4b0<br /> ip6_input_finish+0x44/0x70<br /> ip6_input+0x44/0xc0<br /> ipv6_rcv+0x6c/0x114<br /> __netif_receive_skb_one_core+0x5c/0x8c<br /> __netif_receive_skb+0x18/0x60<br /> process_backlog+0x78/0x17c<br /> __napi_poll+0x38/0x180<br /> net_rx_action+0x168/0x2f0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL deref in debugfs odm_combine_segments<br /> <br /> When a connector is connected but inactive (e.g., disabled by desktop<br /> environments), pipe_ctx-&gt;stream_res.tg will be destroyed. Then, reading<br /> odm_combine_segments causes kernel NULL pointer dereference.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6<br /> Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025<br /> RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu]<br /> Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 8b 07 48 8b 80 08 02 00&gt;<br /> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286<br /> RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8<br /> RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0<br /> R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08<br /> R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001<br /> FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> seq_read_iter+0x125/0x490<br /> ? __alloc_frozen_pages_noprof+0x18f/0x350<br /> seq_read+0x12c/0x170<br /> full_proxy_read+0x51/0x80<br /> vfs_read+0xbc/0x390<br /> ? __handle_mm_fault+0xa46/0xef0<br /> ? do_syscall_64+0x71/0x900<br /> ksys_read+0x73/0xf0<br /> do_syscall_64+0x71/0x900<br /> ? count_memcg_events+0xc2/0x190<br /> ? handle_mm_fault+0x1d7/0x2d0<br /> ? do_user_addr_fault+0x21a/0x690<br /> ? exc_page_fault+0x7e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x6c/0x74<br /> RIP: 0033:0x7f44d4031687<br /> Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 c3 0f 1f 80 00 00 00 00&gt;<br /> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687<br /> RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003<br /> RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000<br /> R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000<br /> <br /> Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x&gt;<br /> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn&gt;<br /> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp&gt;<br /> CR2: 0000000000000000<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu]<br /> Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 8b 07 48 8b 80 08 02 00&gt;<br /> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286<br /> RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8<br /> RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0<br /> R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08<br /> R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001<br /> FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0<br /> PKRU: 55555554<br /> <br /> Fix this by checking pipe_ctx-&gt;<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: Remove calls to drm_put_dev()<br /> <br /> Since the allocation of the drivers main structure was changed to<br /> devm_drm_dev_alloc() drm_put_dev()&amp;#39;ing to trigger it to be free&amp;#39;d<br /> should be done by devres.<br /> <br /> However, drm_put_dev() is still in the probe error and device remove<br /> paths. When the driver fails to probe warnings like the following are<br /> shown because devres is trying to drm_put_dev() after the driver<br /> already did it.<br /> <br /> [ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22<br /> [ 5.649605] ------------[ cut here ]------------<br /> [ 5.649607] refcount_t: underflow; use-after-free.<br /> [ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110<br /> <br /> (cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()<br /> <br /> This code frees "link" by calling kfree_rcu(link, rcu_head) and then it<br /> dereferences "link" to get the "link-&gt;fw_id". Save the "link-&gt;fw_id"<br /> first to avoid a potential use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: don&amp;#39;t clear IMA_DIGSIG flag when setting or removing non-IMA xattr<br /> <br /> Currently when both IMA and EVM are in fix mode, the IMA signature will<br /> be reset to IMA hash if a program first stores IMA signature in<br /> security.ima and then writes/removes some other security xattr for the<br /> file.<br /> <br /> For example, on Fedora, after booting the kernel with "ima_appraise=fix<br /> evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,<br /> installing/reinstalling a package will not make good reference IMA<br /> signature generated. Instead IMA hash is generated,<br /> <br /> # getfattr -m - -d -e hex /usr/bin/bash<br /> # file: usr/bin/bash<br /> security.ima=0x0404...<br /> <br /> This happens because when setting security.selinux, the IMA_DIGSIG flag<br /> that had been set early was cleared. As a result, IMA hash is generated<br /> when the file is closed.<br /> <br /> Similarly, IMA signature can be cleared on file close after removing<br /> security xattr like security.evm or setting/removing ACL.<br /> <br /> Prevent replacing the IMA file signature with a file hash, by preventing<br /> the IMA_DIGSIG flag from being reset.<br /> <br /> Here&amp;#39;s a minimal C reproducer which sets security.selinux as the last<br /> step which can also replaced by removing security.evm or setting ACL,<br /> <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> int main() {<br /> const char* file_path = "/usr/sbin/test_binary";<br /> const char* hex_string = "030204d33204490066306402304";<br /> int length = strlen(hex_string);<br /> char* ima_attr_value;<br /> int fd;<br /> <br /> fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);<br /> if (fd == -1) {<br /> perror("Error opening file");<br /> return 1;<br /> }<br /> <br /> ima_attr_value = (char*)malloc(length / 2 );<br /> for (int i = 0, j = 0; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Disable AFBC support on Mediatek DRM driver<br /> <br /> Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM<br /> driver") added AFBC support to Mediatek DRM and enabled the<br /> 32x8/split/sparse modifier.<br /> <br /> However, this is currently broken on Mediatek MT8188 (Genio 700 EVK<br /> platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by<br /> default since Mesa v25.0.<br /> <br /> Kernel trace reports vblank timeouts constantly, and the render is garbled:<br /> <br /> ```<br /> [CRTC:62:crtc-0] vblank wait timed out<br /> WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c<br /> [...]<br /> Hardware name: MediaTek Genio-700 EVK (DT)<br /> Workqueue: events_unbound commit_work<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c<br /> lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c<br /> sp : ffff80008337bca0<br /> x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000<br /> x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000<br /> x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80<br /> x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a<br /> x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b<br /> x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70<br /> x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70<br /> x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480<br /> Call trace:<br /> drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)<br /> drm_atomic_helper_commit_tail_rpm+0x64/0x80<br /> commit_tail+0xa4/0x1a4<br /> commit_work+0x14/0x20<br /> process_one_work+0x150/0x290<br /> worker_thread+0x2d0/0x3ec<br /> kthread+0x12c/0x210<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> ```<br /> <br /> Until this gets fixed upstream, disable AFBC support on this platform, as<br /> it&amp;#39;s currently broken with upstream Mesa.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Fix streaming cleanup on release<br /> <br /> The current implementation unconditionally calls<br /> mxc_isi_video_cleanup_streaming() in mxc_isi_video_release(). This can<br /> lead to situations where any release call (like from a simple<br /> "v4l2-ctl -l") may release a currently streaming queue when called on<br /> such a device.<br /> <br /> This is reproducible on an i.MX8MP board by streaming from an ISI<br /> capture device using gstreamer:<br /> <br /> gst-launch-1.0 -v v4l2src device=/dev/videoX ! \<br /> video/x-raw,format=GRAY8,width=1280,height=800,framerate=1/120 ! \<br /> fakesink<br /> <br /> While this stream is running, querying the caps of the same device<br /> provokes the error state:<br /> <br /> v4l2-ctl -l -d /dev/videoX<br /> <br /> This results in the following trace:<br /> <br /> [ 155.452152] ------------[ cut here ]------------<br /> [ 155.452163] WARNING: CPU: 0 PID: 1708 at drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c:713 mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]<br /> [ 157.004248] Modules linked in: cfg80211 rpmsg_ctrl rpmsg_char rpmsg_tty virtio_rpmsg_bus rpmsg_ns rpmsg_core rfkill nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables mcp251x6<br /> [ 157.053499] CPU: 0 UID: 0 PID: 1708 Comm: python3 Not tainted 6.15.4-00114-g1f61ca5cad76 #1 PREEMPT<br /> [ 157.064369] Hardware name: imx8mp_board_01 (DT)<br /> [ 157.068205] pstate: 400000c5 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 157.075169] pc : mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi]<br /> [ 157.081195] lr : mxc_isi_pipe_irq_handler+0x38/0x1b0 [imx8_isi]<br /> [ 157.087126] sp : ffff800080003ee0<br /> [ 157.090438] x29: ffff800080003ee0 x28: ffff0000c3688000 x27: 0000000000000000<br /> [ 157.097580] x26: 0000000000000000 x25: ffff0000c1e7ac00 x24: ffff800081b5ad50<br /> [ 157.104723] x23: 00000000000000d1 x22: 0000000000000000 x21: ffff0000c25e4000<br /> [ 157.111866] x20: 0000000060000200 x19: ffff80007a0608d0 x18: 0000000000000000<br /> [ 157.119008] x17: ffff80006a4e3000 x16: ffff800080000000 x15: 0000000000000000<br /> [ 157.126146] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 157.133287] x11: 0000000000000040 x10: ffff0000c01445f0 x9 : ffff80007a053a38<br /> [ 157.140425] x8 : ffff0000c04004b8 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 157.147567] x5 : ffff0000c0400490 x4 : ffff80006a4e3000 x3 : ffff0000c25e4000<br /> [ 157.154706] x2 : 0000000000000000 x1 : ffff8000825c0014 x0 : 0000000060000200<br /> [ 157.161850] Call trace:<br /> [ 157.164296] mxc_isi_pipe_irq_handler+0x19c/0x1b0 [imx8_isi] (P)<br /> [ 157.170319] __handle_irq_event_percpu+0x58/0x218<br /> [ 157.175029] handle_irq_event+0x54/0xb8<br /> [ 157.178867] handle_fasteoi_irq+0xac/0x248<br /> [ 157.182968] handle_irq_desc+0x48/0x68<br /> [ 157.186723] generic_handle_domain_irq+0x24/0x38<br /> [ 157.191346] gic_handle_irq+0x54/0x120<br /> [ 157.195098] call_on_irq_stack+0x24/0x30<br /> [ 157.199027] do_interrupt_handler+0x88/0x98<br /> [ 157.203212] el0_interrupt+0x44/0xc0<br /> [ 157.206792] __el0_irq_handler_common+0x18/0x28<br /> [ 157.211328] el0t_64_irq_handler+0x10/0x20<br /> [ 157.215429] el0t_64_irq+0x198/0x1a0<br /> [ 157.219009] ---[ end trace 0000000000000000 ]---<br /> <br /> Address this issue by moving the streaming preparation and cleanup to<br /> the vb2 .prepare_streaming() and .unprepare_streaming() operations. This<br /> also simplifies the driver by allowing direct usage of the<br /> vb2_ioctl_streamon() and vb2_ioctl_streamoff() helpers, and removal of<br /> the manual cleanup from mxc_isi_video_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: cadence: Check for the existence of cdns_pcie::ops before using it<br /> <br /> cdns_pcie::ops might not be populated by all the Cadence glue drivers. This<br /> is going to be true for the upcoming Sophgo platform which doesn&amp;#39;t set the<br /> ops.<br /> <br /> Hence, add a check to prevent NULL pointer dereference.<br /> <br /> [mani: reworded subject and description]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq/longhaul: handle NULL policy in longhaul_exit<br /> <br /> longhaul_exit() was calling cpufreq_cpu_get(0) without checking<br /> for a NULL policy pointer. On some systems, this could lead to a<br /> NULL dereference and a kernel warning or panic.<br /> <br /> This patch adds a check using unlikely() and returns early if the<br /> policy is NULL.<br /> <br /> Bugzilla: #219962