Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: fix various gadget panics on 10gbps cabling<br /> <br /> usb_assign_descriptors() is called with 5 parameters,<br /> the last 4 of which are the usb_descriptor_header for:<br /> full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),<br /> high-speed (USB2.0 - 480Mbps),<br /> super-speed (USB3.0 - 5Gbps),<br /> super-speed-plus (USB3.1 - 10Gbps).<br /> <br /> The differences between full/high/super-speed descriptors are usually<br /> substantial (due to changes in the maximum usb block size from 64 to 512<br /> to 1024 bytes and other differences in the specs), while the difference<br /> between 5 and 10Gbps descriptors may be as little as nothing<br /> (in many cases the same tuning is simply good enough).<br /> <br /> However if a gadget driver calls usb_assign_descriptors() with<br /> a NULL descriptor for super-speed-plus and is then used on a max 10gbps<br /> configuration, the kernel will crash with a null pointer dereference,<br /> when a 10gbps capable device port + cable + host port combination shows up.<br /> (This wouldn&amp;#39;t happen if the gadget max-speed was set to 5gbps, but<br /> it of course defaults to the maximum, and there&amp;#39;s no real reason to<br /> artificially limit it)<br /> <br /> The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,<br /> if a 10gbps descriptor wasn&amp;#39;t provided.<br /> <br /> Obviously this won&amp;#39;t fix the problem if the 5gbps descriptor is also<br /> NULL, but such cases can&amp;#39;t be so trivially solved (and any such gadgets<br /> are unlikely to be used with USB3 ports any way).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: cancel vdm and state machine hrtimer when unregister tcpm port<br /> <br /> A pending hrtimer may expire after the kthread_worker of tcpm port<br /> is destroyed, see below kernel dump when do module unload, fix it<br /> by cancel the 2 hrtimers.<br /> <br /> [ 111.517018] Unable to handle kernel paging request at virtual address ffff8000118cb880<br /> [ 111.518786] blk_update_request: I/O error, dev sda, sector 60061185 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0<br /> [ 111.526594] Mem abort info:<br /> [ 111.526597] ESR = 0x96000047<br /> [ 111.526600] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 111.526604] SET = 0, FnV = 0<br /> [ 111.526607] EA = 0, S1PTW = 0<br /> [ 111.526610] Data abort info:<br /> [ 111.526612] ISV = 0, ISS = 0x00000047<br /> [ 111.526615] CM = 0, WnR = 1<br /> [ 111.526619] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041d75000<br /> [ 111.526623] [ffff8000118cb880] pgd=10000001bffff003, p4d=10000001bffff003, pud=10000001bfffe003, pmd=10000001bfffa003, pte=0000000000000000<br /> [ 111.526642] Internal error: Oops: 96000047 [#1] PREEMPT SMP<br /> [ 111.526647] Modules linked in: dwc3_imx8mp dwc3 phy_fsl_imx8mq_usb [last unloaded: tcpci]<br /> [ 111.526663] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc4-00927-gebbe9dbd802c-dirty #36<br /> [ 111.526670] Hardware name: NXP i.MX8MPlus EVK board (DT)<br /> [ 111.526674] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO BTYPE=--)<br /> [ 111.526681] pc : queued_spin_lock_slowpath+0x1a0/0x390<br /> [ 111.526695] lr : _raw_spin_lock_irqsave+0x88/0xb4<br /> [ 111.526703] sp : ffff800010003e20<br /> [ 111.526706] x29: ffff800010003e20 x28: ffff00017f380180<br /> [ 111.537156] buffer_io_error: 6 callbacks suppressed<br /> [ 111.537162] Buffer I/O error on dev sda1, logical block 60040704, async page read<br /> [ 111.539932] x27: ffff00017f3801c0<br /> [ 111.539938] x26: ffff800010ba2490 x25: 0000000000000000 x24: 0000000000000001<br /> [ 111.543025] blk_update_request: I/O error, dev sda, sector 60061186 op 0x0:(READ) flags 0x0 phys_seg 7 prio class 0<br /> [ 111.548304]<br /> [ 111.548306] x23: 00000000000000c0 x22: ffff0000c2a9f184 x21: ffff00017f380180<br /> [ 111.551374] Buffer I/O error on dev sda1, logical block 60040705, async page read<br /> [ 111.554499]<br /> [ 111.554503] x20: ffff0000c5f14210 x19: 00000000000000c0 x18: 0000000000000000<br /> [ 111.557391] Buffer I/O error on dev sda1, logical block 60040706, async page read<br /> [ 111.561218]<br /> [ 111.561222] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> [ 111.564205] Buffer I/O error on dev sda1, logical block 60040707, async page read<br /> [ 111.570887] x14: 00000000000000f5 x13: 0000000000000001 x12: 0000000000000040<br /> [ 111.570902] x11: ffff0000c05ac6d8<br /> [ 111.583420] Buffer I/O error on dev sda1, logical block 60040708, async page read<br /> [ 111.588978] x10: 0000000000000000 x9 : 0000000000040000<br /> [ 111.588988] x8 : 0000000000000000<br /> [ 111.597173] Buffer I/O error on dev sda1, logical block 60040709, async page read<br /> [ 111.605766] x7 : ffff00017f384880 x6 : ffff8000118cb880<br /> [ 111.605777] x5 : ffff00017f384880<br /> [ 111.611094] Buffer I/O error on dev sda1, logical block 60040710, async page read<br /> [ 111.617086] x4 : 0000000000000000 x3 : ffff0000c2a9f184<br /> [ 111.617096] x2 : ffff8000118cb880<br /> [ 111.622242] Buffer I/O error on dev sda1, logical block 60040711, async page read<br /> [ 111.626927] x1 : ffff8000118cb880 x0 : ffff00017f384888<br /> [ 111.626938] Call trace:<br /> [ 111.626942] queued_spin_lock_slowpath+0x1a0/0x390<br /> [ 111.795809] kthread_queue_work+0x30/0xc0<br /> [ 111.799828] state_machine_timer_handler+0x20/0x30<br /> [ 111.804624] __hrtimer_run_queues+0x140/0x1e0<br /> [ 111.808990] hrtimer_interrupt+0xec/0x2c0<br /> [ 111.813004] arch_timer_handler_phys+0x38/0x50<br /> [ 111.817456] handle_percpu_devid_irq+0x88/0x150<br /> [ 111.821991] __handle_domain_irq+0x80/0xe0<br /> [ 111.826093] gic_handle_irq+0xc0/0x140<br /> [ 111.829848] el1_irq+0xbc/0x154<br /> [ 111.832991] arch_cpu_idle+0x1c/0x2c<br /> [ 111.836572] default_idle_call+0x24/0x6c<br /> [ 111.840497] do_idle+0x238/0x2ac<br /> [ 1<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: ep0: fix NULL pointer exception<br /> <br /> There is no validation of the index from dwc3_wIndex_to_dep() and we might<br /> be referring a non-existing ep and trigger a NULL pointer exception. In<br /> certain configurations we might use fewer eps and the index might wrongly<br /> indicate a larger ep index than existing.<br /> <br /> By adding this validation from the patch we can actually report a wrong<br /> index back to the caller.<br /> <br /> In our usecase we are using a composite device on an older kernel, but<br /> upstream might use this fix also. Unfortunately, I cannot describe the<br /> hardware for others to reproduce the issue as it is a proprietary<br /> implementation.<br /> <br /> [ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4<br /> [ 82.966891] Mem abort info:<br /> [ 82.969663] ESR = 0x96000006<br /> [ 82.972703] Exception class = DABT (current EL), IL = 32 bits<br /> [ 82.978603] SET = 0, FnV = 0<br /> [ 82.981642] EA = 0, S1PTW = 0<br /> [ 82.984765] Data abort info:<br /> [ 82.987631] ISV = 0, ISS = 0x00000006<br /> [ 82.991449] CM = 0, WnR = 0<br /> [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc<br /> [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000<br /> [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP<br /> [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)<br /> [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1<br /> [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)<br /> [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c<br /> [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94<br /> <br /> ...<br /> <br /> [ 83.141788] Call trace:<br /> [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c<br /> [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94<br /> [ 83.181546] ---[ end trace aac6b5267d84c32f ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: fix various gadgets null ptr deref on 10gbps cabling.<br /> <br /> This avoids a null pointer dereference in<br /> f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}<br /> by simply reusing the 5gbps config for 10gbps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdnsp: Fix deadlock issue in cdnsp_thread_irq_handler<br /> <br /> Patch fixes the following critical issue caused by deadlock which has been<br /> detected during testing NCM class:<br /> <br /> smp: csd: Detected non-responsive CSD lock (#1) on CPU#0<br /> smp: csd: CSD lock (#1) unresponsive.<br /> ....<br /> RIP: 0010:native_queued_spin_lock_slowpath+0x61/0x1d0<br /> RSP: 0018:ffffbc494011cde0 EFLAGS: 00000002<br /> RAX: 0000000000000101 RBX: ffff9ee8116b4a68 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ee8116b4658<br /> RBP: ffffbc494011cde0 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658<br /> R13: ffff9ee8116b4670 R14: 0000000000000246 R15: ffff9ee8116b4658<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7bcc41a830 CR3: 000000007a612003 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> do_raw_spin_lock+0xc0/0xd0<br /> _raw_spin_lock_irqsave+0x95/0xa0<br /> cdnsp_gadget_ep_queue.cold+0x88/0x107 [cdnsp_udc_pci]<br /> usb_ep_queue+0x35/0x110<br /> eth_start_xmit+0x220/0x3d0 [u_ether]<br /> ncm_tx_timeout+0x34/0x40 [usb_f_ncm]<br /> ? ncm_free_inst+0x50/0x50 [usb_f_ncm]<br /> __hrtimer_run_queues+0xac/0x440<br /> hrtimer_run_softirq+0x8c/0xb0<br /> __do_softirq+0xcf/0x428<br /> asm_call_irq_on_stack+0x12/0x20<br /> <br /> do_softirq_own_stack+0x61/0x70<br /> irq_exit_rcu+0xc1/0xd0<br /> sysvec_apic_timer_interrupt+0x52/0xb0<br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> RIP: 0010:do_raw_spin_trylock+0x18/0x40<br /> RSP: 0018:ffffbc494138bda8 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: ffff9ee8116b4658 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9ee8116b4658<br /> RBP: ffffbc494138bda8 R08: 0000000000000001 R09: 0000000000000000<br /> R10: ffff9ee8116b4670 R11: 0000000000000000 R12: ffff9ee8116b4658<br /> R13: ffff9ee8116b4670 R14: ffff9ee7b5c73d80 R15: ffff9ee8116b4000<br /> _raw_spin_lock+0x3d/0x70<br /> ? cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]<br /> cdnsp_thread_irq_handler.cold+0x32/0x112c [cdnsp_udc_pci]<br /> ? cdnsp_remove_request+0x1f0/0x1f0 [cdnsp_udc_pci]<br /> ? cdnsp_thread_irq_handler+0x5/0xa0 [cdnsp_udc_pci]<br /> ? irq_thread+0xa0/0x1c0<br /> irq_thread_fn+0x28/0x60<br /> irq_thread+0x105/0x1c0<br /> ? __kthread_parkme+0x42/0x90<br /> ? irq_forced_thread_fn+0x90/0x90<br /> ? wake_threads_waitq+0x30/0x30<br /> ? irq_thread_check_affinity+0xe0/0xe0<br /> kthread+0x12a/0x160<br /> ? kthread_park+0x90/0x90<br /> ret_from_fork+0x22/0x30<br /> <br /> The root cause of issue is spin_lock/spin_unlock instruction instead<br /> spin_lock_irqsave/spin_lock_irqrestore in cdnsp_thread_irq_handler<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc-&gt;gadget is NULL<br /> <br /> There exists a possible scenario in which dwc3_gadget_init() can fail:<br /> during during host -&gt; peripheral mode switch in dwc3_set_mode(), and<br /> a pending gadget driver fails to bind. Then, if the DRD undergoes<br /> another mode switch from peripheral-&gt;host the resulting<br /> dwc3_gadget_exit() will attempt to reference an invalid and dangling<br /> dwc-&gt;gadget pointer as well as call dma_free_coherent() on unmapped<br /> DMA pointers.<br /> <br /> The exact scenario can be reproduced as follows:<br /> - Start DWC3 in peripheral mode<br /> - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)<br /> - Run FunctionFS userspace application (open EPs, write descriptors, etc)<br /> - Bind gadget driver to DWC3&amp;#39;s UDC<br /> - Switch DWC3 to host mode<br /> =&gt; dwc3_gadget_exit() is called. usb_del_gadget() will put the<br /> ConfigFS driver instance on the gadget_driver_pending_list<br /> - Stop FunctionFS application (closes the ep files)<br /> - Switch DWC3 to peripheral mode<br /> =&gt; dwc3_gadget_init() fails as usb_add_gadget() calls<br /> check_pending_gadget_drivers() and attempts to rebind the UDC<br /> to the ConfigFS gadget but fails with -19 (-ENODEV) because the<br /> FFS instance is not in FFS_ACTIVE state (userspace has not<br /> re-opened and written the descriptors yet, i.e. desc_ready!=0).<br /> - Switch DWC3 back to host mode<br /> =&gt; dwc3_gadget_exit() is called again, but this time dwc-&gt;gadget<br /> is invalid.<br /> <br /> Although it can be argued that userspace should take responsibility<br /> for ensuring that the FunctionFS application be ready prior to<br /> allowing the composite driver bind to the UDC, failure to do so<br /> should not result in a panic from the kernel driver.<br /> <br /> Fix this by setting dwc-&gt;gadget to NULL in the failure path of<br /> dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out<br /> unless the gadget pointer is valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3-meson-g12a: fix usb2 PHY glue init when phy0 is disabled<br /> <br /> When only PHY1 is used (for example on Odroid-HC4), the regmap init code<br /> uses the usb2 ports when doesn&amp;#39;t initialize the PHY1 regmap entry.<br /> <br /> This fixes:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> ...<br /> pc : regmap_update_bits_base+0x40/0xa0<br /> lr : dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8<br /> ...<br /> Call trace:<br /> regmap_update_bits_base+0x40/0xa0<br /> dwc3_meson_g12a_usb2_init_phy+0x4c/0xf8<br /> dwc3_meson_g12a_usb2_init+0x7c/0xc8<br /> dwc3_meson_g12a_usb_init+0x28/0x48<br /> dwc3_meson_g12a_probe+0x298/0x540<br /> platform_probe+0x70/0xe0<br /> really_probe+0xf0/0x4d8<br /> driver_probe_device+0xfc/0x168<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Correct the length check which causes memory corruption<br /> <br /> We&amp;#39;ve suffered from severe kernel crashes due to memory corruption on<br /> our production environment, like,<br /> <br /> Call Trace:<br /> [1640542.554277] general protection fault: 0000 [#1] SMP PTI<br /> [1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G<br /> [1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190<br /> [1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286<br /> [1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:<br /> 0000000006e931bf<br /> [1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:<br /> ffff9a45ff004300<br /> [1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:<br /> 0000000000000000<br /> [1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:<br /> ffffffff9a20608d<br /> [1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:<br /> 696c662f65636976<br /> [1640542.563128] FS: 00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)<br /> knlGS:0000000000000000<br /> [1640542.563937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:<br /> 00000000003606e0<br /> [1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [1640542.566742] Call Trace:<br /> [1640542.567009] anon_vma_clone+0x5d/0x170<br /> [1640542.567417] __split_vma+0x91/0x1a0<br /> [1640542.567777] do_munmap+0x2c6/0x320<br /> [1640542.568128] vm_munmap+0x54/0x70<br /> [1640542.569990] __x64_sys_munmap+0x22/0x30<br /> [1640542.572005] do_syscall_64+0x5b/0x1b0<br /> [1640542.573724] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> [1640542.575642] RIP: 0033:0x7f45d6e61e27<br /> <br /> James Wang has reproduced it stably on the latest 4.19 LTS.<br /> After some debugging, we finally proved that it&amp;#39;s due to ftrace<br /> buffer out-of-bound access using a debug tool as follows:<br /> [ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000<br /> [ 86.780806] no_context+0xdf/0x3c0<br /> [ 86.784327] __do_page_fault+0x252/0x470<br /> [ 86.788367] do_page_fault+0x32/0x140<br /> [ 86.792145] page_fault+0x1e/0x30<br /> [ 86.795576] strncpy_from_unsafe+0x66/0xb0<br /> [ 86.799789] fetch_memory_string+0x25/0x40<br /> [ 86.804002] fetch_deref_string+0x51/0x60<br /> [ 86.808134] kprobe_trace_func+0x32d/0x3a0<br /> [ 86.812347] kprobe_dispatcher+0x45/0x50<br /> [ 86.816385] kprobe_ftrace_handler+0x90/0xf0<br /> [ 86.820779] ftrace_ops_assist_func+0xa1/0x140<br /> [ 86.825340] 0xffffffffc00750bf<br /> [ 86.828603] do_sys_open+0x5/0x1f0<br /> [ 86.832124] do_syscall_64+0x5b/0x1b0<br /> [ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> commit b220c049d519 ("tracing: Check length before giving out<br /> the filter buffer") adds length check to protect trace data<br /> overflow introduced in 0fc1b09ff1ff, seems that this fix can&amp;#39;t prevent<br /> overflow entirely, the length check should also take the sizeof<br /> entry-&gt;array[0] into account, since this array[0] is filled the<br /> length of trace data and occupy addtional space and risk overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: avoid oversized read request in cache missing code path<br /> <br /> In the cache missing code path of cached device, if a proper location<br /> from the internal B+ tree is matched for a cache miss range, function<br /> cached_dev_cache_miss() will be called in cache_lookup_fn() in the<br /> following code block,<br /> [code block 1]<br /> 526 unsigned int sectors = KEY_INODE(k) == s-&gt;iop.inode<br /> 527 ? min_t(uint64_t, INT_MAX,<br /> 528 KEY_START(k) - bio-&gt;bi_iter.bi_sector)<br /> 529 : INT_MAX;<br /> 530 int ret = s-&gt;d-&gt;cache_miss(b, s, bio, sectors);<br /> <br /> Here s-&gt;d-&gt;cache_miss() is the call backfunction pointer initialized as<br /> cached_dev_cache_miss(), the last parameter &amp;#39;sectors&amp;#39; is an important<br /> hint to calculate the size of read request to backing device of the<br /> missing cache data.<br /> <br /> Current calculation in above code block may generate oversized value of<br /> &amp;#39;sectors&amp;#39;, which consequently may trigger 2 different potential kernel<br /> panics by BUG() or BUG_ON() as listed below,<br /> <br /> 1) BUG_ON() inside bch_btree_insert_key(),<br /> [code block 2]<br /> 886 BUG_ON(b-&gt;ops-&gt;is_extents &amp;&amp; !KEY_SIZE(k));<br /> 2) BUG() inside biovec_slab(),<br /> [code block 3]<br /> 51 default:<br /> 52 BUG();<br /> 53 return NULL;<br /> <br /> All the above panics are original from cached_dev_cache_miss() by the<br /> oversized parameter &amp;#39;sectors&amp;#39;.<br /> <br /> Inside cached_dev_cache_miss(), parameter &amp;#39;sectors&amp;#39; is used to calculate<br /> the size of data read from backing device for the cache missing. This<br /> size is stored in s-&gt;insert_bio_sectors by the following lines of code,<br /> [code block 4]<br /> 909 s-&gt;insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);<br /> <br /> Then the actual key inserting to the internal B+ tree is generated and<br /> stored in s-&gt;iop.replace_key by the following lines of code,<br /> [code block 5]<br /> 911 s-&gt;iop.replace_key = KEY(s-&gt;iop.inode,<br /> 912 bio-&gt;bi_iter.bi_sector + s-&gt;insert_bio_sectors,<br /> 913 s-&gt;insert_bio_sectors);<br /> The oversized parameter &amp;#39;sectors&amp;#39; may trigger panic 1) by BUG_ON() from<br /> the above code block.<br /> <br /> And the bio sending to backing device for the missing data is allocated<br /> with hint from s-&gt;insert_bio_sectors by the following lines of code,<br /> [code block 6]<br /> 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT,<br /> 927 DIV_ROUND_UP(s-&gt;insert_bio_sectors, PAGE_SECTORS),<br /> 928 &amp;dc-&gt;disk.bio_split);<br /> The oversized parameter &amp;#39;sectors&amp;#39; may trigger panic 2) by BUG() from the<br /> agove code block.<br /> <br /> Now let me explain how the panics happen with the oversized &amp;#39;sectors&amp;#39;.<br /> In code block 5, replace_key is generated by macro KEY(). From the<br /> definition of macro KEY(),<br /> [code block 7]<br /> 71 #define KEY(inode, offset, size) \<br /> 72 ((struct bkey) { \<br /> 73 .high = (1ULL

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Do not blindly read the ip address in ftrace_bug()<br /> <br /> It was reported that a bug on arm64 caused a bad ip address to be used for<br /> updating into a nop in ftrace_init(), but the error path (rightfully)<br /> returned -EINVAL and not -EFAULT, as the bug caused more than one error to<br /> occur. But because -EINVAL was returned, the ftrace_bug() tried to report<br /> what was at the location of the ip address, and read it directly. This<br /> caused the machine to panic, as the ip was not pointing to a valid memory<br /> address.<br /> <br /> Instead, read the ip address with copy_from_kernel_nofault() to safely<br /> access the memory, and if it faults, report that the address faulted,<br /> otherwise report what was in that location.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix skb length check in ieee80211_scan_rx()<br /> <br /> Replace hard-coded compile-time constants for header length check<br /> with dynamic determination based on the frame type. Otherwise, we<br /> hit a validation WARN_ON in cfg80211 later.<br /> <br /> [style fixes, reword commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Avoid WARN_ON timing related checks<br /> <br /> The soft/batadv interface for a queued OGM can be changed during the time<br /> the OGM was queued for transmission and when the OGM is actually<br /> transmitted by the worker.<br /> <br /> But WARN_ON must be used to denote kernel bugs and not to print simple<br /> warnings. A warning can simply be printed using pr_warn.