eth: bnxt: always recalculate features after XDP clearing, fix null-deref

In the Linux kernel, the following vulnerability has been resolved:

net: fec: handle pagepooldevallocpages error

The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.

This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.

Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.

This commit handles the allocation error by dropping the current packet.

In the Linux kernel, the following vulnerability has been resolved:

iouring/eventfd: ensure ioeventfdsignal() defers another RCU period

ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.

Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: clamp maximum hashtable size to INTMAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from initnetns.

In the Linux kernel, the following vulnerability has been resolved:

platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it

Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wakedepth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged:

kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irqsetirqwake+0x147/0x1a0

The PMC driver uses DEFINESIMPLEDEVPMOPS() to define its devpmops which sets amdpmcsuspendhandler() to the .suspend, .freeze, and .poweroff handlers. i8042pmsuspend(), however, is only set as the .suspend handler.

Fix the issue by call PMC suspend handler only from the same set of devpmops handlers as i8042pmsuspend(), which currently means just the .suspend handler.

To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first.

[ij: edited the commit message.]

fs: relax assertions on failure to encode file handles

In the Linux kernel, the following vulnerability has been resolved:

topology: Keep the cpumask unchanged when printing cpumap

During fuzz testing, the following warning was discovered:

different return values (15 and 11) from vsnprintf("%pbl ", ...)

test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2

The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:

(1) First, calculate the length of the resulting formatted string.

(2) Allocate a buffer based on the returned length.

(3) Then, perform the actual string formatting.

(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.

If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.

To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.

In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: fix TSO DMA API usage causing oops

Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of txskbuffdma[]'s members to be later in stmmactsoxmit().

The buf (dma cookie) and len stored in this structure are passed to dmaunmapsingle() by stmmactxclean(). The DMA API requires that the dma cookie passed to dmaunmapsingle() is the same as the value returned from dmamapsingle(). However, by moving the assignment later, this is not the case when priv->dmacap.addr64 > 32 as "des" is offset by protohdrlen.

This causes problems such as:

dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed

and with DMAAPIDEBUG enabled:

DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]

Fix this by maintaining "des" as the original DMA cookie, and use tsodes to pass the offset DMA cookie to stmmactsoallocator().

Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/

In the Linux kernel, the following vulnerability has been resolved:

scsi: sg: Fix slab-use-after-free read in sgrelease()

Fix a use-after-free bug in sgrelease(), detected by syzbot with KASAN:

BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sgrelease+0x1f4/0x2e0 drivers/scsi/sg.c:407

In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfpusercontext(), which ultimately frees sfp.

After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.

Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures:

- No references to sfp or sdp occur after the reference count is decremented.

- Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease().

The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sgrelease().

In the Linux kernel, the following vulnerability has been resolved:

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswapcompress() and zswapdecompress(), the per-CPU acompctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.

Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acompctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.

The initialization of acompctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.

Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronizesrcu() cannot be used in CPU hotplug notifiers [2].

Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acompctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.

[1]

bpf: check changespktdata property for extension programs

afpacket: fix vlangetprotocoldgram() vs MSGPEEK

afpacket: fix vlangettci() vs MSGPEEK

In the Linux kernel, the following vulnerability has been resolved:

riscv: Fix sleeping in invalid context in die()

die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlockt which can sleep with PREEMPTRT enabled. That causes the following warning:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 285, name: mutex preemptcount: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dumpbacktrace+0x1c/0x24 showstack+0x2c/0x38 dumpstacklvl+0x5a/0x72 dumpstack+0x14/0x1c mightresched+0x130/0x13a rtspinlock+0x2a/0x5c die+0x24/0x112 dotrapinsnillegal+0xa0/0xea newvmallocrestorecontexta0+0xcc/0xd8 Oops - illegal instruction [#1]

Switch to use rawspinlockt, which does not sleep even with PREEMPTRT enabled.

In the Linux kernel, the following vulnerability has been resolved:

virtio-blk: don't keep queue frozen during system suspend

Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending.

block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bioqueueenter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblkfreeze().

[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/

Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.

gfs2: Truncate address space when flipping GFS2DIFJDATA flag

drm/v3d: Ensure job pointer is set to NULL after job completion

hrtimers: Handle CPU state correctly on hotplug

fs/proc: fix softlockup in readvmcore (part 2)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: netem: account for backlog updates from child qdisc

In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisctreereducebacklog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full.

Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms

Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif>

Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0

Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0

tbf segments the GSO SKBs (tbfsegment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted.

This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics.

btrfs: avoid NULL pointer dereference if no valid extent tree

exfat: fix the infinite loop in exfatreaddir()

In the Linux kernel, the following vulnerability has been resolved:

net/sctp: Prevent autoclose integer overflow in sctpassociationinit()

While by default maxautoclose equals to INTMAX / HZ, one may set net.sctp.maxautoclose to UINTMAX. There is code in sctpassociationinit() that can consequently trigger overflow.

In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix TCP options overflow.

Syzbot reported the following splat:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:compoundhead include/linux/page-flags.h:242 [inline] RIP: 0010:putpage+0x23/0x260 include/linux/mm.h:1552 Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83 RSP: 0000:ffffc90003916c90 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007 R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpageunref include/linux/skbuffref.h:43 [inline] skbfragunref include/linux/skbuffref.h:56 [inline] skbreleasedata+0x483/0x8a0 net/core/skbuff.c:1119 skbreleaseall net/core/skbuff.c:1190 [inline] kfreeskb+0x55/0x70 net/core/skbuff.c:1204 tcpcleanrtxqueue net/ipv4/tcpinput.c:3436 [inline] tcpack+0x2442/0x6bc0 net/ipv4/tcpinput.c:4032 tcprcvstateprocess+0x8eb/0x44e0 net/ipv4/tcpinput.c:6805 tcpv4dorcv+0x77d/0xc70 net/ipv4/tcpipv4.c:1939 tcpv4rcv+0x2dc0/0x37f0 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x22e/0x440 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x341/0x5f0 net/ipv4/ipinput.c:233 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 netifreceiveskbonecore net/core/dev.c:5672 [inline] netifreceiveskb+0x2bf/0x650 net/core/dev.c:5785 processbacklog+0x662/0x15b0 net/core/dev.c:6117 napipoll+0xcb/0x490 net/core/dev.c:6883 napipoll net/core/dev.c:6952 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:7074 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049 asmsysvecapictimerinterrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0033:0x7f34f4519ad5 Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246 RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5 RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0 RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000 R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4 R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68 </TASK>

Eric noted a probable shinfo->nrfrags corruption, which indeed occurs.

The root cause is a buggy MPTCP option len computation in some circumstances: the ADDADDR option should be mutually exclusive with DSS since the blamed commit.

Still, mptcpestablishedoptionsaddaddr() tries to set the relevant info in mptcpoutoptions, if ---truncated---

drm/amd/display: Add check for granularity in dml ceil/floor helpers

ila: serialize calls to nfregisternethooks()

In the Linux kernel, the following vulnerability has been resolved:

net: fix memory leak in tcpconnrequest()

If inetcskreqskqueuehashadd() return false, tcpconnrequest() will return without free the dst memory, which allocated in afops->routereq.

Here is the kmemleak stack:

unreferenced object 0xffff8881198631c0 (size 240): comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s) hex dump (first 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [<ffffffffb93e8d4c>] kmemcachealloc+0x60c/0xa80 [<ffffffffba11b4c5>] dstalloc+0x55/0x250 [<ffffffffba227bf6>] rtdstalloc+0x46/0x1d0 [<ffffffffba23050a>] mkrouteoutput+0x29a/0xa50 [<ffffffffba23456b>] iprouteoutputkeyhash+0x10b/0x240 [<ffffffffba2346bd>] iprouteoutputflow+0x1d/0x90 [<ffffffffba254855>] inetcskroutereq+0x2c5/0x500 [<ffffffffba26b331>] tcpconnrequest+0x691/0x12c0 [<ffffffffba27bd08>] tcprcvstateprocess+0x3c8/0x11b0 [<ffffffffba2965c6>] tcpv4dorcv+0x156/0x3b0 [<ffffffffba299c98>] tcpv4rcv+0x1cf8/0x1d80 [<ffffffffba239656>] ipprotocoldeliverrcu+0xf6/0x360 [<ffffffffba2399a6>] iplocaldeliverfinish+0xe6/0x1e0 [<ffffffffba239b8e>] iplocaldeliver+0xee/0x360 [<ffffffffba239ead>] iprcv+0xad/0x2f0 [<ffffffffba110943>] netifreceiveskbonecore+0x123/0x140

Call dstrelease() to free the dst memory when inetcskreqskqueuehashadd() return false in tcpconnrequest().

In the Linux kernel, the following vulnerability has been resolved:

sctp: sysctl: udpport: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using containerof().

Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctlsock' still needs to be retrieved from 'net' structure.

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: ffs: Remove WARNON in functionfsbind

This commit addresses an issue related to below kernel panic where paniconwarn is enabled. It is caused by the unnecessary use of WARNON in functionsfsbind, which easily leads to the following scenarios.

1.adbwrite in adbd 2. UDC write via configfs ================= =====================

->usbffsopenthread() ->UDC write ->openfunctionfs() ->configfswriteiter() ->adbopen() ->gadgetdevdescUDCstore() ->adbwrite() ->usbgadgetregisterdriverowner ->driverregister() ->StartMonitor() ->busadddriver() ->adbread() ->gadgetbinddriver() <times-out without BIND event> ->configfscompositebind() ->usbaddfunction() ->openfunctionfs() ->ffsfuncbind() ->adbopen() ->functionfsbind() <ffs->state !=FFSACTIVE>

The adbopen, adbread, and adbwrite operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARNON from functionfsbind when paniconwarn is enabled. This commit fixes the kernel panic by removing the unnecessary WARNON.

Kernel panic - not syncing: kernel: paniconwarn set ... [ 14.542395] Call trace: [ 14.542464] ffsfuncbind+0x1c8/0x14a8 [ 14.542468] usbaddfunction+0xcc/0x1f0 [ 14.542473] configfscompositebind+0x468/0x588 [ 14.542478] gadgetbinddriver+0x108/0x27c [ 14.542483] reallyprobe+0x190/0x374 [ 14.542488] driverprobedevice+0xa0/0x12c [ 14.542492] driverprobedevice+0x3c/0x220 [ 14.542498] driverattach+0x11c/0x1fc [ 14.542502] busforeachdev+0x104/0x160 [ 14.542506] driverattach+0x24/0x34 [ 14.542510] busadddriver+0x154/0x270 [ 14.542514] driverregister+0x68/0x104 [ 14.542518] usbgadgetregisterdriverowner+0x48/0xf4 [ 14.542523] gadgetdevdescUDCstore+0xf8/0x144 [ 14.542526] configfswriteiter+0xf0/0x138

btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount