Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix potential memory leak on unlikely error case<br /> <br /> If skb_linearize is needed and fails we could leak a msg on the error<br /> handling. To fix ensure we kfree the msg block before returning error.<br /> Found during code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp, net: Fix use-after-free in bpf_xdp_link_release<br /> <br /> The problem occurs between dev_get_by_index() and dev_xdp_attach_link().<br /> At this point, dev_xdp_uninstall() is called. Then xdp link will not be<br /> detached automatically when dev is released. But link-&gt;dev already<br /> points to dev, when xdp link is released, dev will still be accessed,<br /> but dev has been released.<br /> <br /> dev_get_by_index() |<br /> link-&gt;dev = dev |<br /> | rtnl_lock()<br /> | unregister_netdevice_many()<br /> | dev_xdp_uninstall()<br /> | rtnl_unlock()<br /> rtnl_lock(); |<br /> dev_xdp_attach_link() |<br /> rtnl_unlock(); |<br /> | netdev_run_todo() // dev released<br /> bpf_xdp_link_release() |<br /> /* access dev. |<br /> use-after-free */ |<br /> <br /> [ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0<br /> [ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732<br /> [ 45.968297]<br /> [ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22<br /> [ 45.969222] Hardware name: linux,dummy-virt (DT)<br /> [ 45.969795] Call trace:<br /> [ 45.970106] dump_backtrace+0x0/0x4c8<br /> [ 45.970564] show_stack+0x30/0x40<br /> [ 45.970981] dump_stack_lvl+0x120/0x18c<br /> [ 45.971470] print_address_description.constprop.0+0x74/0x30c<br /> [ 45.972182] kasan_report+0x1e8/0x200<br /> [ 45.972659] __asan_report_load8_noabort+0x2c/0x50<br /> [ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0<br /> [ 45.973834] bpf_link_free+0xd0/0x188<br /> [ 45.974315] bpf_link_put+0x1d0/0x218<br /> [ 45.974790] bpf_link_release+0x3c/0x58<br /> [ 45.975291] __fput+0x20c/0x7e8<br /> [ 45.975706] ____fput+0x24/0x30<br /> [ 45.976117] task_work_run+0x104/0x258<br /> [ 45.976609] do_notify_resume+0x894/0xaf8<br /> [ 45.977121] work_pending+0xc/0x328<br /> [ 45.977575]<br /> [ 45.977775] The buggy address belongs to the page:<br /> [ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998<br /> [ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)<br /> [ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000<br /> [ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> [ 45.982259] page dumped because: kasan: bad access detected<br /> [ 45.982948]<br /> [ 45.983153] Memory state around the buggy address:<br /> [ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.985533] &gt;ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.986419] ^<br /> [ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> [ 45.988895] ==================================================================<br /> [ 45.989773] Disabling lock debugging due to kernel taint<br /> [ 45.990552] Kernel panic - not syncing: panic_on_warn set ...<br /> [ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22<br /> [ 45.991929] Hardware name: linux,dummy-virt (DT)<br /> [ 45.992448] Call trace:<br /> [ 45.992753] dump_backtrace+0x0/0x4c8<br /> [ 45.993208] show_stack+0x30/0x40<br /> [ 45.993627] dump_stack_lvl+0x120/0x18c<br /> [ 45.994113] dump_stack+0x1c/0x34<br /> [ 45.994530] panic+0x3a4/0x7d8<br /> [ 45.994930] end_report+0x194/0x198<br /> [ 45.995380] kasan_report+0x134/0x200<br /> [ 45.995850] __asan_report_load8_noabort+0x2c/0x50<br /> [ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0<br /> [ 45.997007] bpf_link_free+0xd0/0x188<br /> [ 45.997474] bpf_link_put+0x1d0/0x218<br /> [ 45.997942] bpf_link_release+0x3c/0x58<br /> [ 45.998429] __fput+0x20c/0x7e8<br /> [ 45.998833] ____fput+0x24/0x30<br /> [ 45.999247] task_work_run+0x104/0x258<br /> [ 45.999731] do_notify_resume+0x894/0xaf8<br /> [ 46.000236] work_pending<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix tail_call_reachable rejection for interpreter when jit failed<br /> <br /> During testing of f263a81451c1 ("bpf: Track subprog poke descriptors correctly<br /> and fix use-after-free") under various failure conditions, for example, when<br /> jit_subprogs() fails and tries to clean up the program to be run under the<br /> interpreter, we ran into the following freeze:<br /> <br /> [...]<br /> #127/8 tailcall_bpf2bpf_3:FAIL<br /> [...]<br /> [ 92.041251] BUG: KASAN: slab-out-of-bounds in ___bpf_prog_run+0x1b9d/0x2e20<br /> [ 92.042408] Read of size 8 at addr ffff88800da67f68 by task test_progs/682<br /> [ 92.043707]<br /> [ 92.044030] CPU: 1 PID: 682 Comm: test_progs Tainted: G O 5.13.0-53301-ge6c08cb33a30-dirty #87<br /> [ 92.045542] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014<br /> [ 92.046785] Call Trace:<br /> [ 92.047171] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.047773] ? __bpf_prog_run_args32+0x8b/0xb0<br /> [ 92.048389] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.049019] ? ktime_get+0x117/0x130<br /> [...] // few hundred [similar] lines more<br /> [ 92.659025] ? ktime_get+0x117/0x130<br /> [ 92.659845] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.660738] ? __bpf_prog_run_args32+0x8b/0xb0<br /> [ 92.661528] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.662378] ? print_usage_bug+0x50/0x50<br /> [ 92.663221] ? print_usage_bug+0x50/0x50<br /> [ 92.664077] ? bpf_ksym_find+0x9c/0xe0<br /> [ 92.664887] ? ktime_get+0x117/0x130<br /> [ 92.665624] ? kernel_text_address+0xf5/0x100<br /> [ 92.666529] ? __kernel_text_address+0xe/0x30<br /> [ 92.667725] ? unwind_get_return_address+0x2f/0x50<br /> [ 92.668854] ? ___bpf_prog_run+0x15d4/0x2e20<br /> [ 92.670185] ? ktime_get+0x117/0x130<br /> [ 92.671130] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.672020] ? __bpf_prog_run_args32+0x8b/0xb0<br /> [ 92.672860] ? __bpf_prog_run_args64+0xc0/0xc0<br /> [ 92.675159] ? ktime_get+0x117/0x130<br /> [ 92.677074] ? lock_is_held_type+0xd5/0x130<br /> [ 92.678662] ? ___bpf_prog_run+0x15d4/0x2e20<br /> [ 92.680046] ? ktime_get+0x117/0x130<br /> [ 92.681285] ? __bpf_prog_run32+0x6b/0x90<br /> [ 92.682601] ? __bpf_prog_run64+0x90/0x90<br /> [ 92.683636] ? lock_downgrade+0x370/0x370<br /> [ 92.684647] ? mark_held_locks+0x44/0x90<br /> [ 92.685652] ? ktime_get+0x117/0x130<br /> [ 92.686752] ? lockdep_hardirqs_on+0x79/0x100<br /> [ 92.688004] ? ktime_get+0x117/0x130<br /> [ 92.688573] ? __cant_migrate+0x2b/0x80<br /> [ 92.689192] ? bpf_test_run+0x2f4/0x510<br /> [ 92.689869] ? bpf_test_timer_continue+0x1c0/0x1c0<br /> [ 92.690856] ? rcu_read_lock_bh_held+0x90/0x90<br /> [ 92.691506] ? __kasan_slab_alloc+0x61/0x80<br /> [ 92.692128] ? eth_type_trans+0x128/0x240<br /> [ 92.692737] ? __build_skb+0x46/0x50<br /> [ 92.693252] ? bpf_prog_test_run_skb+0x65e/0xc50<br /> [ 92.693954] ? bpf_prog_test_run_raw_tp+0x2d0/0x2d0<br /> [ 92.694639] ? __fget_light+0xa1/0x100<br /> [ 92.695162] ? bpf_prog_inc+0x23/0x30<br /> [ 92.695685] ? __sys_bpf+0xb40/0x2c80<br /> [ 92.696324] ? bpf_link_get_from_fd+0x90/0x90<br /> [ 92.697150] ? mark_held_locks+0x24/0x90<br /> [ 92.698007] ? lockdep_hardirqs_on_prepare+0x124/0x220<br /> [ 92.699045] ? finish_task_switch+0xe6/0x370<br /> [ 92.700072] ? lockdep_hardirqs_on+0x79/0x100<br /> [ 92.701233] ? finish_task_switch+0x11d/0x370<br /> [ 92.702264] ? __switch_to+0x2c0/0x740<br /> [ 92.703148] ? mark_held_locks+0x24/0x90<br /> [ 92.704155] ? __x64_sys_bpf+0x45/0x50<br /> [ 92.705146] ? do_syscall_64+0x35/0x80<br /> [ 92.706953] ? entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [...]<br /> <br /> Turns out that the program rejection from e411901c0b77 ("bpf: allow for tailcalls<br /> in BPF subprograms for x64 JIT") is buggy since env-&gt;prog-&gt;aux-&gt;tail_call_reachable<br /> is never true. Commit ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall<br /> handling in JIT") added a tracker into check_max_stack_depth() which propagates<br /> the tail_call_reachable condition throughout the subprograms. This info is then<br /> assigned to the subprogram&amp;#39;s <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Fix use-after-free error during reset<br /> <br /> Cleans the next descriptor to watch (next_to_watch) when cleaning the<br /> TX ring.<br /> <br /> Failure to do so can cause invalid memory accesses. If igb_poll() runs<br /> while the controller is reset this can lead to the driver try to free<br /> a skb that was already freed.<br /> <br /> (The crash is harder to reproduce with the igb driver, but the same<br /> potential problem exists as the code is identical to igc)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: Fix use-after-free error during reset<br /> <br /> Cleans the next descriptor to watch (next_to_watch) when cleaning the<br /> TX ring.<br /> <br /> Failure to do so can cause invalid memory accesses. If igc_poll() runs<br /> while the controller is being reset this can lead to the driver try to<br /> free a skb that was already freed.<br /> <br /> Log message:<br /> <br /> [ 101.525242] refcount_t: underflow; use-after-free.<br /> [ 101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0<br /> [ 101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)<br /> x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)<br /> ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)<br /> rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)<br /> soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)<br /> iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)<br /> soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)<br /> autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)<br /> i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)<br /> [ 101.525303] drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)<br /> e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)<br /> usbcore(E) drm(E) button(E) video(E)<br /> [ 101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G E 5.10.30-rt37-tsn1-rt-ipipe #ipipe<br /> [ 101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017<br /> [ 101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0<br /> [ 101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48<br /> 44 01 01 e8 d1 c6 42 00 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3<br /> [ 101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286<br /> [ 101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001<br /> [ 101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff<br /> [ 101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50<br /> [ 101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00<br /> [ 101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40<br /> [ 101.525337] FS: 0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000<br /> [ 101.525339] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0<br /> [ 101.525343] Call Trace:<br /> [ 101.525346] sock_wfree+0x9c/0xa0<br /> [ 101.525353] unix_destruct_scm+0x7b/0xa0<br /> [ 101.525358] skb_release_head_state+0x40/0x90<br /> [ 101.525362] skb_release_all+0xe/0x30<br /> [ 101.525364] napi_consume_skb+0x57/0x160<br /> [ 101.525367] igc_poll+0xb7/0xc80 [igc]<br /> [ 101.525376] ? sched_clock+0x5/0x10<br /> [ 101.525381] ? sched_clock_cpu+0xe/0x100<br /> [ 101.525385] net_rx_action+0x14c/0x410<br /> [ 101.525388] __do_softirq+0xe9/0x2f4<br /> [ 101.525391] __local_bh_enable_ip+0xe3/0x110<br /> [ 101.525395] ? irq_finalize_oneshot.part.47+0xe0/0xe0<br /> [ 101.525398] irq_forced_thread_fn+0x6a/0x80<br /> [ 101.525401] irq_thread+0xe8/0x180<br /> [ 101.525403] ? wake_threads_waitq+0x30/0x30<br /> [ 101.525406] ? irq_thread_check_affinity+0xd0/0xd0<br /> [ 101.525408] kthread+0x183/0x1a0<br /> [ 101.525412] ? kthread_park+0x80/0x80<br /> [ 101.525415] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: fix memory leak in tcindex_partial_destroy_work<br /> <br /> Syzbot reported memory leak in tcindex_set_parms(). The problem was in<br /> non-freed perfect hash in tcindex_partial_destroy_work().<br /> <br /> In tcindex_set_parms() new tcindex_data is allocated and some fields from<br /> old one are copied to new one, but not the perfect hash. Since<br /> tcindex_partial_destroy_work() is the destroy function for old<br /> tcindex_data, we need to free perfect hash to avoid memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kvm: avoid speculation-based attacks from out-of-range memslot accesses<br /> <br /> KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical<br /> address (gpa) to a host virtual address using the right-shifted gpa<br /> (also known as gfn) and a struct kvm_memory_slot. The translation is<br /> performed in __gfn_to_hva_memslot using the following formula:<br /> <br /> hva = slot-&gt;userspace_addr + (gfn - slot-&gt;base_gfn) * PAGE_SIZE<br /> <br /> It is expected that gfn falls within the boundaries of the guest&amp;#39;s<br /> physical memory. However, a guest can access invalid physical addresses<br /> in such a way that the gfn is invalid.<br /> <br /> __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first<br /> retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot<br /> does check that the gfn falls within the boundaries of the guest&amp;#39;s<br /> physical memory or not, a CPU can speculate the result of the check and<br /> continue execution speculatively using an illegal gfn. The speculation<br /> can result in calculating an out-of-bounds hva. If the resulting host<br /> virtual address is used to load another guest physical address, this<br /> is effectively a Spectre gadget consisting of two consecutive reads,<br /> the second of which is data dependent on the first.<br /> <br /> Right now it&amp;#39;s not clear if there are any cases in which this is<br /> exploitable. One interesting case was reported by the original author<br /> of this patch, and involves visiting guest page tables on x86. Right<br /> now these are not vulnerable because the hva read goes through get_user(),<br /> which contains an LFENCE speculation barrier. However, there are<br /> patches in progress for x86 uaccess.h to mask kernel addresses instead of<br /> using LFENCE; once these land, a guest could use speculation to read<br /> from the VMM&amp;#39;s ring 3 address space. Other architectures such as ARM<br /> already use the address masking method, and would be susceptible to<br /> this same kind of data-dependent access gadgets. Therefore, this patch<br /> proactively protects from these attacks by masking out-of-bounds gfns<br /> in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.<br /> <br /> Sean Christopherson noted that this patch does not cover<br /> kvm_read_guest_offset_cached. This however is limited to a few bytes<br /> past the end of the cache, and therefore it is unlikely to be useful in<br /> the context of building a chain of data dependent accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()<br /> <br /> This driver&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: misc: brcmstb-usb-pinmap: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Fix use-after-free read in drm_getunique()<br /> <br /> There is a time-of-check-to-time-of-use error in drm_getunique() due<br /> to retrieving file_priv-&gt;master prior to locking the device&amp;#39;s master<br /> mutex.<br /> <br /> An example can be seen in the crash report of the use-after-free error<br /> found by Syzbot:<br /> https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803<br /> <br /> In the report, the master pointer was used after being freed. This is<br /> because another process had acquired the device&amp;#39;s master mutex in<br /> drm_setmaster_ioctl(), then overwrote fpriv-&gt;master in<br /> drm_new_set_master(). The old value of fpriv-&gt;master was subsequently<br /> freed before the mutex was unlocked.<br /> <br /> To fix this, we lock the device&amp;#39;s master mutex before retrieving the<br /> pointer from from fpriv-&gt;master. This patch passes the Syzbot<br /> reproducer test.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: seq: Fix race of snd_seq_timer_open()<br /> <br /> The timer instance per queue is exclusive, and snd_seq_timer_open()<br /> should have managed the concurrent accesses. It looks as if it&amp;#39;s<br /> checking the already existing timer instance at the beginning, but<br /> it&amp;#39;s not right, because there is no protection, hence any later<br /> concurrent call of snd_seq_timer_open() may override the timer<br /> instance easily. This may result in UAF, as the leftover timer<br /> instance can keep running while the queue itself gets closed, as<br /> spotted by syzkaller recently.<br /> <br /> For avoiding the race, add a proper check at the assignment of<br /> tmr-&gt;timeri again, and return -EBUSY if it&amp;#39;s been already registered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: bcm2835: Fix out-of-bounds access with more than 4 slaves<br /> <br /> Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for<br /> -&gt;prepare_message()") limited the number of slaves to 3 at compile-time.<br /> The limitation was necessitated by a statically-sized array prepare_cs[]<br /> in the driver private data which contains a per-slave register value.<br /> <br /> The commit sought to enforce the limitation at run-time by setting the<br /> controller&amp;#39;s num_chipselect to 3: Slaves with a higher chipselect are<br /> rejected by spi_add_device().<br /> <br /> However the commit neglected that num_chipselect only limits the number<br /> of *native* chipselects. If GPIO chipselects are specified in the<br /> device tree for more than 3 slaves, num_chipselect is silently raised by<br /> of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to<br /> the statically-sized array prepare_cs[].<br /> <br /> As a bandaid fix which is backportable to stable, raise the number of<br /> allowed slaves to 24 (which "ought to be enough for anybody"), enforce<br /> the limitation on slave -&gt;setup and revert num_chipselect to 3 (which is<br /> the number of native chipselects supported by the controller).<br /> An upcoming for-next commit will allow an arbitrary number of slaves.