Need to talk to a real person Avelo Airlines? Calling Avelo Airlines directly at π 1-866-897-5122. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch.
In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy.
βοΈ First Things First: Call 1-866-897-5122
The most direct and reliable way to speak with a real Avelo Airlines representative is by calling π 1-866-897-5122. This is Frontierβs official customer service number and should be your go-to for:
βοΈ Flight changes or cancellations
π§Ύ Refund or credit questions
π Baggage issues
π Name corrections
π Check-in or boarding problems
πΊ Seat selection and upgrades
Pro Tip: When calling, try to do so during non-peak hours β early mornings or late evenings β to reduce your hold time.
π§ How to Navigate the Automated Menu
When you call 1-866-897-5122, you will first hear an automated system. To get through to a live person faster, follow these steps:
Dial 1-866-897-5122
Wait for the automated greeting to begin
Press β1β for English (or β2β for Spanish)
Press β2β for existing reservations
Press β0β to speak with an agent (you may need to press "0" more than once)
π If β0β does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input.
If the lines are busy and you are placed on hold, do not hang up β wait times vary, but you will eventually reach someone.
π§Ύ What to Have Ready Before You Call
To help the agent assist you faster, make sure you have the following details on hand:
π Your confirmation code or booking number
π The full name on the reservation
π Your flight date and destination
π Any relevant documents (ID, credit card, etc.)
π A notepad for writing down instructions or confirmation numbers
If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request.
β° Best Times to Call 1-866-897-5122
Customer service lines can be busy, especially during:
β οΈ Holidays
β οΈ Severe weather or flight delays
β οΈ Early morning flight hours
π― For the best chance at a short wait, try calling during these times:
π 5:00 AM β 7:00 AM (EST)
π 9:00 PM β 11:00 PM (EST)
π Midweek (Tuesdays and Wednesdays)
Avoid Mondays if possible β it is the busiest day for airlines.
π§βπ» Alternative Ways to Reach Avelo Airlines (If Phone Fails)
If calling π 1-866-897-5122 does not work or you are stuck in a long queue, here are a few alternate ways to get help:
π¬ 1. Online Chat (Limited Availability)
Visit www.flyfrontier.com
Scroll down and look for the βLetβs Chatβ option.
This can connect you to a live agent or AI assistant, depending on availability.
π§ 2. Email Support
You can also submit a help request through their Customer Support Form online.
Use this for non-urgent matters like refund requests or documentation review.
π± 3. Social Media
Tweet or DM Avelo Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook.
Sometimes social media agents respond faster than the phone team during high-volume periods.
π² 4. Mobile App
Download the Avelo Airlines App, log in, and navigate to βMy Tripsβ or βSupportβ for quick options.
While this will not guarantee a live agent, you might find answers to basic questions faster.
β Common Issues That Require a Live Agent
While many tasks can be done online, certain problems are best resolved with a real person at 1-866-897-5122:
π Double charges or billing issues
π Complex flight changes involving multiple passengers
π Lost or delayed baggage
βοΈ Legal name changes (marriage, divorce, etc.)
π§ββοΈ Medical or accessibility needs during travel
In these cases, avoid wasting time β call directly and ask for a live agent.
π¨ Beware of Fake Numbers and Scams
Only use the official number: π 1-866-897-5122.
Scammers often post fake βFrontier supportβ numbers online, asking for credit card info or login credentials.
π‘οΈ Never share your full credit card number or personal information with an unverified source.
β Final Thoughts
Talking to a live person at an airline should not be this hard β but when it comes to Avelo Airlines, knowing the right steps and phone number makes all the difference.
π§ Remember:
Dial π 1-866-897-5122
Press 0 to reach a live agent
Call during off-peak hours
Have your booking info ready
Use alternative methods if the line is too busy
π‘ The sooner you reach out, the more options you'll have to resolve your issue.
βοΈ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-897-5122 connects you with someone who can truly help.
Need to talk to a real person Caribbean Airlines? Calling Caribbean Airlines directly at π 1-866-897-5122. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch.
In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy.
βοΈ First Things First: Call 1-866-897-5122
The most direct and reliable way to speak with a real Caribbean Airlines representative is by calling π 1-866-897-5122. This is Frontierβs official customer service number and should be your go-to for:
βοΈ Flight changes or cancellations
π§Ύ Refund or credit questions
π Baggage issues
π Name corrections
π Check-in or boarding problems
πΊ Seat selection and upgrades
Pro Tip: When calling, try to do so during non-peak hours β early mornings or late evenings β to reduce your hold time.
π§ How to Navigate the Automated Menu
When you call 1-866-897-5122, you will first hear an automated system. To get through to a live person faster, follow these steps:
Dial 1-866-897-5122
Wait for the automated greeting to begin
Press β1β for English (or β2β for Spanish)
Press β2β for existing reservations
Press β0β to speak with an agent (you may need to press "0" more than once)
π If β0β does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input.
If the lines are busy and you are placed on hold, do not hang up β wait times vary, but you will eventually reach someone.
π§Ύ What to Have Ready Before You Call
To help the agent assist you faster, make sure you have the following details on hand:
π Your confirmation code or booking number
π The full name on the reservation
π Your flight date and destination
π Any relevant documents (ID, credit card, etc.)
π A notepad for writing down instructions or confirmation numbers
If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request.
β° Best Times to Call 1-866-897-5122
Customer service lines can be busy, especially during:
β οΈ Holidays
β οΈ Severe weather or flight delays
β οΈ Early morning flight hours
π― For the best chance at a short wait, try calling during these times:
π 5:00 AM β 7:00 AM (EST)
π 9:00 PM β 11:00 PM (EST)
π Midweek (Tuesdays and Wednesdays)
Avoid Mondays if possible β it is the busiest day for airlines.
π§βπ» Alternative Ways to Reach Caribbean Airlines (If Phone Fails)
If calling π 1-866-897-5122 does not work or you are stuck in a long queue, here are a few alternate ways to get help:
π¬ 1. Online Chat (Limited Availability)
Visit www.flyfrontier.com
Scroll down and look for the βLetβs Chatβ option.
This can connect you to a live agent or AI assistant, depending on availability.
π§ 2. Email Support
You can also submit a help request through their Customer Support Form online.
Use this for non-urgent matters like refund requests or documentation review.
π± 3. Social Media
Tweet or DM Caribbean Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook.
Sometimes social media agents respond faster than the phone team during high-volume periods.
π² 4. Mobile App
Download the Caribbean Airlines App, log in, and navigate to βMy Tripsβ or βSupportβ for quick options.
While this will not guarantee a live agent, you might find answers to basic questions faster.
β Common Issues That Require a Live Agent
While many tasks can be done online, certain problems are best resolved with a real person at 1-866-897-5122:
π Double charges or billing issues
π Complex flight changes involving multiple passengers
π Lost or delayed baggage
βοΈ Legal name changes (marriage, divorce, etc.)
π§ββοΈ Medical or accessibility needs during travel
In these cases, avoid wasting time β call directly and ask for a live agent.
π¨ Beware of Fake Numbers and Scams
Only use the official number: π 1-866-897-5122.
Scammers often post fake βFrontier supportβ numbers online, asking for credit card info or login credentials.
π‘οΈ Never share your full credit card number or personal information with an unverified source.
β Final Thoughts
Talking to a live person at an airline should not be this hard β but when it comes to Caribbean Airlines, knowing the right steps and phone number makes all the difference.
π§ Remember:
Dial π 1-866-897-5122
Press 0 to reach a live agent
Call during off-peak hours
Have your booking info ready
Use alternative methods if the line is too busy
π‘ The sooner you reach out, the more options you'll have to resolve your issue.
βοΈ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-897-5122 connects you with someone who can truly help.
The quilt patch titled
Subject: um: disable KASAN_INLINE when STATIC_LINK is selected
has been removed from the -mm tree. Its filename was
um-disable-kasan_inline-when-static_link-is-selected.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: "Christophe Leroy (CS GROUP)" <chleroy(a)kernel.org>
Subject: um: disable KASAN_INLINE when STATIC_LINK is selected
Date: Sat, 29 Nov 2025 10:56:02 +0100
um doesn't support KASAN_INLINE together with STATIC_LINK.
Instead of failing the build, disable KASAN_INLINE when
STATIC_LINK is selected.
Link: https://lkml.kernel.org/r/2620ab0bbba640b6237c50b9c0dca1c7d1142f5d.17644100β¦
Fixes: 1e338f4d99e6 ("kasan: introduce ARCH_DEFER_KASAN and unify static key across modes")
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy(a)kernel.org>
Reported-by: kernel test robot <lkp(a)intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511290451.x9GZVJ1l-lkp@intel.com/
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Andrey Konovalov <andreyknvl(a)gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com>
Cc: Anton Ivanov <anton.ivanov(a)cambridgegreys.com>
Cc: Dmitriy Vyukov <dvyukov(a)google.com>
Cc: Johannes Berg <johannes(a)sipsolutions.net>
Cc: Richard Weinberger <richard(a)nod.at>
Cc: "Ritesh Harjani (IBM)" <ritesh.list(a)gmail.com>
Cc: Sabyrzhan Tasbolatov <snovitoll(a)gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino(a)arm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/um/Kconfig | 1 +
arch/um/include/asm/kasan.h | 4 ----
2 files changed, 1 insertion(+), 4 deletions(-)
--- a/arch/um/include/asm/kasan.h~um-disable-kasan_inline-when-static_link-is-selected
+++ a/arch/um/include/asm/kasan.h
@@ -24,10 +24,6 @@
#ifdef CONFIG_KASAN
void kasan_init(void);
-
-#if defined(CONFIG_STATIC_LINK) && defined(CONFIG_KASAN_INLINE)
-#error UML does not work in KASAN_INLINE mode with STATIC_LINK enabled!
-#endif
#else
static inline void kasan_init(void) { }
#endif /* CONFIG_KASAN */
--- a/arch/um/Kconfig~um-disable-kasan_inline-when-static_link-is-selected
+++ a/arch/um/Kconfig
@@ -5,6 +5,7 @@ menu "UML-specific options"
config UML
bool
default y
+ select ARCH_DISABLE_KASAN_INLINE if STATIC_LINK
select ARCH_NEEDS_DEFER_KASAN if STATIC_LINK
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_HAS_CACHE_LINE_SIZE
_
Patches currently in -mm which might be from chleroy(a)kernel.org are
Hello,
Status summary for stable/linux-6.6.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.6.y/4791134e4aebe300af2b409dc550610β¦
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.6.y
commit hash: 4791134e4aebe300af2b409dc550610ef69fae3e
origin: maestro
test start time: 2025-12-01 11:00:03.299000+00:00
Builds: 35 β 4 β 0 β οΈ
Boots: 94 β 0 β 0 β οΈ
Tests: 3919 β 364 β 1563 β οΈ
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- ltp
last run: https://d.kernelci.org/test/maestro:692ddc5ef5b8743b1f6f8407
history: > β > β > β > β > β
This branch has 4 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: β PASS β FAIL β οΈ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci(a)lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
Hello,
Status summary for stable/linux-6.12.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.12.y/318a47068f7b88de838518897500d7β¦
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.12.y
commit hash: 318a47068f7b88de838518897500d7509e3fe205
origin: maestro
test start time: 2025-12-01 11:00:03.719000+00:00
Builds: 34 β 5 β 0 β οΈ
Boots: 189 β 0 β 0 β οΈ
Tests: 11205 β 810 β 2936 β οΈ
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- ltp
last run: https://d.kernelci.org/test/maestro:692d842ef5b8743b1f6ef8d2
history: > β > β > β > β > β
### UNSTABLE TESTS
No unstable tests observed.
This branch has 5 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: β PASS β FAIL β οΈ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci(a)lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
The patch below does not apply to the 6.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x baeb66fbd4201d1c4325074e78b1f557dff89b5b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120122-submitter-flame-5478@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From baeb66fbd4201d1c4325074e78b1f557dff89b5b Mon Sep 17 00:00:00 2001
From: Jimmy Hu <hhhuuu(a)google.com>
Date: Thu, 23 Oct 2025 05:49:45 +0000
Subject: [PATCH] usb: gadget: udc: fix use-after-free in usb_gadget_state_work
A race condition during gadget teardown can lead to a use-after-free
in usb_gadget_state_work(), as reported by KASAN:
BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0
Workqueue: events usb_gadget_state_work
The fundamental race occurs because a concurrent event (e.g., an
interrupt) can call usb_gadget_set_state() and schedule gadget->work
at any time during the cleanup process in usb_del_gadget().
Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after
device removal") attempted to fix this by moving flush_work() to after
device_del(). However, this does not fully solve the race, as a new
work item can still be scheduled *after* flush_work() completes but
before the gadget's memory is freed, leading to the same use-after-free.
This patch fixes the race condition robustly by introducing a 'teardown'
flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is
set during cleanup in usb_del_gadget() *before* calling flush_work() to
prevent any new work from being scheduled once cleanup has commenced.
The scheduling site, usb_gadget_set_state(), now checks this flag under
the lock before queueing the work, thus safely closing the race window.
Fixes: 5702f75375aa9 ("usb: gadget: udc-core: move sysfs_notify() to a workqueue")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Jimmy Hu <hhhuuu(a)google.com>
Link: https://patch.msgid.link/20251023054945.233861-1-hhhuuu@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 694653761c44..8dbe79bdc0f9 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1126,8 +1126,13 @@ static void usb_gadget_state_work(struct work_struct *work)
void usb_gadget_set_state(struct usb_gadget *gadget,
enum usb_device_state state)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(&gadget->state_lock, flags);
gadget->state = state;
- schedule_work(&gadget->work);
+ if (!gadget->teardown)
+ schedule_work(&gadget->work);
+ spin_unlock_irqrestore(&gadget->state_lock, flags);
trace_usb_gadget_set_state(gadget, 0);
}
EXPORT_SYMBOL_GPL(usb_gadget_set_state);
@@ -1361,6 +1366,8 @@ static void usb_udc_nop_release(struct device *dev)
void usb_initialize_gadget(struct device *parent, struct usb_gadget *gadget,
void (*release)(struct device *dev))
{
+ spin_lock_init(&gadget->state_lock);
+ gadget->teardown = false;
INIT_WORK(&gadget->work, usb_gadget_state_work);
gadget->dev.parent = parent;
@@ -1535,6 +1542,7 @@ EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
void usb_del_gadget(struct usb_gadget *gadget)
{
struct usb_udc *udc = gadget->udc;
+ unsigned long flags;
if (!udc)
return;
@@ -1548,6 +1556,13 @@ void usb_del_gadget(struct usb_gadget *gadget)
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
sysfs_remove_link(&udc->dev.kobj, "gadget");
device_del(&gadget->dev);
+ /*
+ * Set the teardown flag before flushing the work to prevent new work
+ * from being scheduled while we are cleaning up.
+ */
+ spin_lock_irqsave(&gadget->state_lock, flags);
+ gadget->teardown = true;
+ spin_unlock_irqrestore(&gadget->state_lock, flags);
flush_work(&gadget->work);
ida_free(&gadget_id_numbers, gadget->id_number);
cancel_work_sync(&udc->vbus_work);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3aaf19e77558..8285b19a25e0 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -376,6 +376,9 @@ struct usb_gadget_ops {
* can handle. The UDC must support this and all slower speeds and lower
* number of lanes.
* @state: the state we are now (attached, suspended, configured, etc)
+ * @state_lock: Spinlock protecting the `state` and `teardown` members.
+ * @teardown: True if the device is undergoing teardown, used to prevent
+ * new work from being scheduled during cleanup.
* @name: Identifies the controller hardware type. Used in diagnostics
* and sometimes configuration.
* @dev: Driver model state for this abstract device.
@@ -451,6 +454,8 @@ struct usb_gadget {
enum usb_ssp_rate max_ssp_rate;
enum usb_device_state state;
+ spinlock_t state_lock;
+ bool teardown;
const char *name;
struct device dev;
unsigned isoch_delay;
The patch below does not apply to the 6.6-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y
git checkout FETCH_HEAD
git cherry-pick -x baeb66fbd4201d1c4325074e78b1f557dff89b5b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120122-shelter-unlit-af6a@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From baeb66fbd4201d1c4325074e78b1f557dff89b5b Mon Sep 17 00:00:00 2001
From: Jimmy Hu <hhhuuu(a)google.com>
Date: Thu, 23 Oct 2025 05:49:45 +0000
Subject: [PATCH] usb: gadget: udc: fix use-after-free in usb_gadget_state_work
A race condition during gadget teardown can lead to a use-after-free
in usb_gadget_state_work(), as reported by KASAN:
BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0
Workqueue: events usb_gadget_state_work
The fundamental race occurs because a concurrent event (e.g., an
interrupt) can call usb_gadget_set_state() and schedule gadget->work
at any time during the cleanup process in usb_del_gadget().
Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after
device removal") attempted to fix this by moving flush_work() to after
device_del(). However, this does not fully solve the race, as a new
work item can still be scheduled *after* flush_work() completes but
before the gadget's memory is freed, leading to the same use-after-free.
This patch fixes the race condition robustly by introducing a 'teardown'
flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is
set during cleanup in usb_del_gadget() *before* calling flush_work() to
prevent any new work from being scheduled once cleanup has commenced.
The scheduling site, usb_gadget_set_state(), now checks this flag under
the lock before queueing the work, thus safely closing the race window.
Fixes: 5702f75375aa9 ("usb: gadget: udc-core: move sysfs_notify() to a workqueue")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Jimmy Hu <hhhuuu(a)google.com>
Link: https://patch.msgid.link/20251023054945.233861-1-hhhuuu@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 694653761c44..8dbe79bdc0f9 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1126,8 +1126,13 @@ static void usb_gadget_state_work(struct work_struct *work)
void usb_gadget_set_state(struct usb_gadget *gadget,
enum usb_device_state state)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(&gadget->state_lock, flags);
gadget->state = state;
- schedule_work(&gadget->work);
+ if (!gadget->teardown)
+ schedule_work(&gadget->work);
+ spin_unlock_irqrestore(&gadget->state_lock, flags);
trace_usb_gadget_set_state(gadget, 0);
}
EXPORT_SYMBOL_GPL(usb_gadget_set_state);
@@ -1361,6 +1366,8 @@ static void usb_udc_nop_release(struct device *dev)
void usb_initialize_gadget(struct device *parent, struct usb_gadget *gadget,
void (*release)(struct device *dev))
{
+ spin_lock_init(&gadget->state_lock);
+ gadget->teardown = false;
INIT_WORK(&gadget->work, usb_gadget_state_work);
gadget->dev.parent = parent;
@@ -1535,6 +1542,7 @@ EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
void usb_del_gadget(struct usb_gadget *gadget)
{
struct usb_udc *udc = gadget->udc;
+ unsigned long flags;
if (!udc)
return;
@@ -1548,6 +1556,13 @@ void usb_del_gadget(struct usb_gadget *gadget)
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
sysfs_remove_link(&udc->dev.kobj, "gadget");
device_del(&gadget->dev);
+ /*
+ * Set the teardown flag before flushing the work to prevent new work
+ * from being scheduled while we are cleaning up.
+ */
+ spin_lock_irqsave(&gadget->state_lock, flags);
+ gadget->teardown = true;
+ spin_unlock_irqrestore(&gadget->state_lock, flags);
flush_work(&gadget->work);
ida_free(&gadget_id_numbers, gadget->id_number);
cancel_work_sync(&udc->vbus_work);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3aaf19e77558..8285b19a25e0 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -376,6 +376,9 @@ struct usb_gadget_ops {
* can handle. The UDC must support this and all slower speeds and lower
* number of lanes.
* @state: the state we are now (attached, suspended, configured, etc)
+ * @state_lock: Spinlock protecting the `state` and `teardown` members.
+ * @teardown: True if the device is undergoing teardown, used to prevent
+ * new work from being scheduled during cleanup.
* @name: Identifies the controller hardware type. Used in diagnostics
* and sometimes configuration.
* @dev: Driver model state for this abstract device.
@@ -451,6 +454,8 @@ struct usb_gadget {
enum usb_ssp_rate max_ssp_rate;
enum usb_device_state state;
+ spinlock_t state_lock;
+ bool teardown;
const char *name;
struct device dev;
unsigned isoch_delay;
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x baeb66fbd4201d1c4325074e78b1f557dff89b5b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120121-sift-shiny-dd51@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From baeb66fbd4201d1c4325074e78b1f557dff89b5b Mon Sep 17 00:00:00 2001
From: Jimmy Hu <hhhuuu(a)google.com>
Date: Thu, 23 Oct 2025 05:49:45 +0000
Subject: [PATCH] usb: gadget: udc: fix use-after-free in usb_gadget_state_work
A race condition during gadget teardown can lead to a use-after-free
in usb_gadget_state_work(), as reported by KASAN:
BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0
Workqueue: events usb_gadget_state_work
The fundamental race occurs because a concurrent event (e.g., an
interrupt) can call usb_gadget_set_state() and schedule gadget->work
at any time during the cleanup process in usb_del_gadget().
Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after
device removal") attempted to fix this by moving flush_work() to after
device_del(). However, this does not fully solve the race, as a new
work item can still be scheduled *after* flush_work() completes but
before the gadget's memory is freed, leading to the same use-after-free.
This patch fixes the race condition robustly by introducing a 'teardown'
flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is
set during cleanup in usb_del_gadget() *before* calling flush_work() to
prevent any new work from being scheduled once cleanup has commenced.
The scheduling site, usb_gadget_set_state(), now checks this flag under
the lock before queueing the work, thus safely closing the race window.
Fixes: 5702f75375aa9 ("usb: gadget: udc-core: move sysfs_notify() to a workqueue")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Jimmy Hu <hhhuuu(a)google.com>
Link: https://patch.msgid.link/20251023054945.233861-1-hhhuuu@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 694653761c44..8dbe79bdc0f9 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1126,8 +1126,13 @@ static void usb_gadget_state_work(struct work_struct *work)
void usb_gadget_set_state(struct usb_gadget *gadget,
enum usb_device_state state)
{
+ unsigned long flags;
+
+ spin_lock_irqsave(&gadget->state_lock, flags);
gadget->state = state;
- schedule_work(&gadget->work);
+ if (!gadget->teardown)
+ schedule_work(&gadget->work);
+ spin_unlock_irqrestore(&gadget->state_lock, flags);
trace_usb_gadget_set_state(gadget, 0);
}
EXPORT_SYMBOL_GPL(usb_gadget_set_state);
@@ -1361,6 +1366,8 @@ static void usb_udc_nop_release(struct device *dev)
void usb_initialize_gadget(struct device *parent, struct usb_gadget *gadget,
void (*release)(struct device *dev))
{
+ spin_lock_init(&gadget->state_lock);
+ gadget->teardown = false;
INIT_WORK(&gadget->work, usb_gadget_state_work);
gadget->dev.parent = parent;
@@ -1535,6 +1542,7 @@ EXPORT_SYMBOL_GPL(usb_add_gadget_udc);
void usb_del_gadget(struct usb_gadget *gadget)
{
struct usb_udc *udc = gadget->udc;
+ unsigned long flags;
if (!udc)
return;
@@ -1548,6 +1556,13 @@ void usb_del_gadget(struct usb_gadget *gadget)
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
sysfs_remove_link(&udc->dev.kobj, "gadget");
device_del(&gadget->dev);
+ /*
+ * Set the teardown flag before flushing the work to prevent new work
+ * from being scheduled while we are cleaning up.
+ */
+ spin_lock_irqsave(&gadget->state_lock, flags);
+ gadget->teardown = true;
+ spin_unlock_irqrestore(&gadget->state_lock, flags);
flush_work(&gadget->work);
ida_free(&gadget_id_numbers, gadget->id_number);
cancel_work_sync(&udc->vbus_work);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3aaf19e77558..8285b19a25e0 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -376,6 +376,9 @@ struct usb_gadget_ops {
* can handle. The UDC must support this and all slower speeds and lower
* number of lanes.
* @state: the state we are now (attached, suspended, configured, etc)
+ * @state_lock: Spinlock protecting the `state` and `teardown` members.
+ * @teardown: True if the device is undergoing teardown, used to prevent
+ * new work from being scheduled during cleanup.
* @name: Identifies the controller hardware type. Used in diagnostics
* and sometimes configuration.
* @dev: Driver model state for this abstract device.
@@ -451,6 +454,8 @@ struct usb_gadget {
enum usb_ssp_rate max_ssp_rate;
enum usb_device_state state;
+ spinlock_t state_lock;
+ bool teardown;
const char *name;
struct device dev;
unsigned isoch_delay;
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x 26d56a9fcb2014b99e654127960aa0a48a391e3c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120132-patio-vocation-ff6a@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 26d56a9fcb2014b99e654127960aa0a48a391e3c Mon Sep 17 00:00:00 2001
From: Owen Gu <guhuinan(a)xiaomi.com>
Date: Thu, 20 Nov 2025 20:33:36 +0800
Subject: [PATCH] usb: uas: fix urb unmapping issue when the uas device is
remove during ongoing data transfer
When a UAS device is unplugged during data transfer, there is
a probability of a system panic occurring. The root cause is
an access to an invalid memory address during URB callback handling.
Specifically, this happens when the dma_direct_unmap_sg() function
is called within the usb_hcd_unmap_urb_for_dma() interface, but the
sg->dma_address field is 0 and the sg data structure has already been
freed.
The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()
in uas.c, using the uas_submit_urbs() function to submit requests to USB.
Within the uas_submit_urbs() implementation, three URBs (sense_urb,
data_urb, and cmd_urb) are sequentially submitted. Device removal may
occur at any point during uas_submit_urbs execution, which may result
in URB submission failure. However, some URBs might have been successfully
submitted before the failure, and uas_submit_urbs will return the -ENODEV
error code in this case. The current error handling directly calls
scsi_done(). In the SCSI driver, this eventually triggers scsi_complete()
to invoke scsi_end_request() for releasing the sgtable. The successfully
submitted URBs, when being unlinked to giveback, call
usb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sg
unmapping operations since the sg data structure has already been freed.
This patch modifies the error condition check in the uas_submit_urbs()
function. When a UAS device is removed but one or more URBs have already
been successfully submitted to USB, it avoids immediately invoking
scsi_done() and save the cmnd to devinfo->cmnd array. If the successfully
submitted URBs is completed before devinfo->resetting being set, then
the scsi_done() function will be called within uas_try_complete() after
all pending URB operations are finalized. Otherwise, the scsi_done()
function will be called within uas_zap_pending(), which is executed after
usb_kill_anchored_urbs().
The error handling only takes effect when uas_queuecommand_lck() calls
uas_submit_urbs() and returns the error value -ENODEV . In this case,
the device is disconnected, and the flow proceeds to uas_disconnect(),
where uas_zap_pending() is invoked to call uas_try_complete().
Fixes: eb2a86ae8c54 ("USB: UAS: fix disconnect by unplugging a hub")
Cc: stable <stable(a)kernel.org>
Signed-off-by: Yu Chen <chenyu45(a)xiaomi.com>
Signed-off-by: Owen Gu <guhuinan(a)xiaomi.com>
Acked-by: Oliver Neukum <oneukum(a)suse.com>
Link: https://patch.msgid.link/20251120123336.3328-1-guhuinan@xiaomi.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 4ed0dc19afe0..45b01df364f7 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -698,6 +698,10 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd)
* of queueing, no matter how fatal the error
*/
if (err == -ENODEV) {
+ if (cmdinfo->state & (COMMAND_INFLIGHT | DATA_IN_URB_INFLIGHT |
+ DATA_OUT_URB_INFLIGHT))
+ goto out;
+
set_host_byte(cmnd, DID_NO_CONNECT);
scsi_done(cmnd);
goto zombie;
@@ -711,6 +715,7 @@ static int uas_queuecommand_lck(struct scsi_cmnd *cmnd)
uas_add_work(cmnd);
}
+out:
devinfo->cmnd[idx] = cmnd;
zombie:
spin_unlock_irqrestore(&devinfo->lock, flags);