
GNU/Linux enthusiast - @openSUSE member - Sysadmin & DevOPS - Also known as Alefnode
Joined March 2011
- Tweets2K
- Following226
- Followers605
- Likes805
Hace unos meses publiqué esto y la verdad es que es una maravilla lo que he montado, viendolo desde la perspectiva de haberlo usado durante meses a diario blog.alefnode.com/blog/mi-ia…
En breves me tocará hablar con @borjaperfra y @barckcode sobre unas dudas que tengo sobre @helmcode a ver si seria factible integrarlo en una empresa
El "SMS de la muerte" te puede dejar sin móvil, sin que puedas hacer nada para evitarlo.
Una vulnerabilidad descubierta por Mark Blaszczyk puede dejar un móvil Android prácticamente inutilizable de forma remota, sin que el usuario haga absolutamente nada.
No es un brick permanente. No destruye el firmware ni el hardware, y existen métodos de recuperación que no requieren borrar todos los datos.
La vulnerabilidad, bautizada como SMS of Death (SMS de la muerte), se divulgó ayer (29 de octubre de 2026).
Lo preocupante es que permite interrumpir llamadas telefónicas, incluidas las realizadas al 112, y provocar un bucle de fallos persistente.
Mark lo reprodujo en móviles Pixel y Samsung.
smsofdeath.com/
¿Cómo funciona técnicamente?
El problema está en WapPushOverSms.decodeWapPdu(), dentro del framework de telefonía de Android.
El ataque aprovecha un SMS de datos WAP Push.
1. El atacante envía un mensaje especialmente manipulado, sin necesitar que la víctima abra nada.
2. Android interpreta automáticamente una longitud de cabecera codificada como uintvar.
3. El parser convierte un valor de 64 bits (long) a un entero con signo de 32 bits (int) sin comprobar su rango.
4. Una longitud inicialmente positiva se convierte en negativa y provoca una excepción Java no controlada.
5. El proceso com.android.phone termina inesperadamente.
El ejemplo concreto es:
long valor = 0x80000000L; // 2147483648
int longitud = (int) valor; // -2147483648
byte[] cabecera = new byte[longitud];
// NegativeArraySizeException
Esto no permite ejecutar código arbitrario ni obtener privilegios de administrador. Es un ataque de denegación de servicio remoto, zero-click.
Lo grave viene después, el SMS malformado puede permanecer en la cola de mensajes pendientes y Android vuelve a intentar procesarlo.
Además, el operador puede retransmitirlo cuando no recibe confirmación de entrega.
El resultado es que el proceso vuelve a fallar, incluso después de reiniciar el dispositivo.
En determinadas condiciones, el mecanismo de recuperación de Android (RescueParty) puede terminar enviándolo al modo recovery.
¿Por qué ni un hard reset lo arregla?
- El reinicio normal puede seguir fallando porque el SMS permanece en la cola.
- El restablecimiento de fábricaborra la cola local, pero el problema puede reaparecer si el operador retransmite el SMS.
La reinstalación del sistema con el parche corrige la vulnerabilidad, siempre que se instale una versión que incorpore la solución.
Por tanto, no es que el factory reset sea incapaz de reparar el teléfono. Es que el operador puede volver a entregarte el mensaje malicioso.
Esto hace que el teléfono parezca brickeado indefinidamente.
Se podría recuperar aislando primero el teléfono de la red móvil, evitando nuevas entregas, y eliminando los mensajes pendientes mediante ADB si está disponible.
Mark Blaszczyk documenta una recuperación sin pérdida de datos manipulando la cola content://sms/raw. Para ello se necesita acceso ADB autorizado y una breve ventana en la que Android haya arrancado.
### Google dice que no es un problema de seguridad
Google ya había desarrollado una corrección (un commit del 15 de junio de 2026), pero según Blaszczyk, su programa de recompensas rechazaba el informe como un problema no relacionado con la seguridad (lo que sea por ahorrase pagar ¿eh?).
android.googlesource.com/pla…
El cambio captura la excepción y elimina el mensaje problemático de la base de datos, impidiendo que vuelva a producir el bucle.
Es decir, Google reconoce expresamente en el código que está solucionando una denegación de servicio remota.
- La vulnerabilidad se identifica ahora como CVE-2026-58882, con clasificación crítica.
- La corrección llegó a Android 14–17 en octubre de 2026.
- GrapheneOS confirma que ya la incorporaba en sus versiones de seguridad anticipadas de julio.
- Los Android 12 y 13 sin soporte seguramente serán vulnerables de forma indefinida.
Lo grave es que no hay forma fácil de protegerse. El SMS malicioso se procesa automáticamente en el subsistema de telefonía de Android, antes de llegar a Google Messages o cualquier otra aplicación de SMS.
Nada de esto funciona:
- Desactivar Google Messages.
- Desactivar las notificaciones SMS.
- Quitar el permiso SMS a las aplicaciones.
Si aun no has recibido el SMS, activar el modo avión o desactivar la SIM/eSIM evita el fallo, pero claro, te quedas sin poder usarlo.
No está claro aun, pero podría ser que poniendo el móvil en modo avión y usando luego VoWiFi, el ataque pudiera fallar, pero vamos, que no es tampoco una solución muy buena.
Con esto, cualquiera que nos quiera joder el móvil, sólo tiene que enviarnos un SMS malicioso, es inquietante.
Recordad que hoy es probable que no tengáis internet en España a partir de/esta tarde #laligagate
Adrian Campos Garrido retweeted
The Mobile #Linux community in #Czechia is thriving; Hackday #8 set a new #Prague attendance record and had to merge two meeting rooms to fit everyone. 🇨🇿📱🐧 news.opensuse.org/2026/09/01…
Phosh 0.58.0 now building on @openSUSE OBS for mobile 📱
• phosh, phoc, xdg-desktop-portal-phosh, phosh-mobile-settings → 0.58.0
• wlroots: + text-input-v3 v2 patches
• Regenerated Rust vendor
All green on aarch64 ✅
Good news for Pinephone users! 🐧 The @openSUSE image for the @thepine64 Pinephone is being upgraded, with both Phosh and Plasma Mobile images coming soon. I had to add some tweaks and disable FDE by default (for now) to avoid overheating.
@openSUSE_ES @pine64eu
Ugh, today I deleted almost 62 OBS repos from my home repo in #openSUSE, just by misediting the project config. Luckily I had a copy on my PC, so I just performed the migration to git for 70% of these repos. I will continue migrating because now the sdm845 image is broken.
Estoy trasteando con LiteLLM, no esta nada mal si tienes varias GPU en distintos hardware sirviendo el mismo modelo para dar más capacidad al cluster si pretendes compartirlo.
a Tsinghua University lab just put a project on GitHub that replaces a $400,000 H100 rack with a single 24GB graphics card.
it's called ktransformers, and the trick is almost stupidly simple: the experts you actually use stay on the gpu, the ones you don't sit on the cpu until they're called
/ deepseek-v3 and r1 with 139K context in 24gb of vram
/ up to 28x speedup over the standard setup
/ fine-tune deepseek-v3 across four rtx 4090s instead of a datacenter
/ built by tsinghua university's madsys lab, not a startup with a landing page
apache 2.0, and already past 17,000 stars.
-> github.com/kvcache-ai/ktrans…
bookmark it.









