why sms doesn't crash a smartphone
At those who question if the carriers filter these, who knows? The researchers ran their own private SMSC and cell site inside a farrady cage for their tests. I could see equipment dropping the ones that crashed the phone by for instance claiming 10 segments when there are really 7 (since a cursory inspection indicates they are corrupted).. On the other hand, if the "outer envelope" of the text is structurally sound I wouldn't expect the equipment to look at content.
As a bad analogy, I expect most ISPs will drop corrupted packets, and drop "bogons" (packets that "got out" to begin wtih due to misconfiguration, like 127.0.0.1 or 192.168.0.x or the like) and drop corrupted packets (bad checksum). I *wouldn't* expect them as a matter of course to inspect packets for virus or malware payloads.
As for smartphones being less susceptible -- I don't think it's because they use both a baseband and service CPU (as opposed to simpler phones using the "baseband" CPU to run the whole show.) I think it's because smartphone OSes have memory protection and multitasking (instead of cooperative task switching*). So the text handler can never overwrite another area of the phone, and if it locks up it doesn't lock the phone. A daemon could watch for hung things like the text handler, and automatically kill the hung one and restart a clean copy. The watchdog counts down from (for instance) 10 seconds; a healthy phone resets the watchdog back to 10 seconds frequently, a hung phone the watchdog resets the phone when the countdown reaches 0.
*With multitasking, the OS runs an app for one timeslice (often 1/100th of a second), and when that 1/100th of a second is up the system stops that app dead in it's tracks and goes to the next one. Cooperative task switching was improperly called multitasking by both Microsoft (pre-Win95) and Apple (pre-OSX), an app runs until it says it's done running. Yes, that means if an app gets stuck in a loop or locks up for any reason, the entire system locks up.