CVE-2022-49509

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: max9286: fix kernel oops when removing module<br /> <br /> When removing the max9286 module we get a kernel oops:<br /> <br /> Unable to handle kernel paging request at virtual address 000000aa00000094<br /> Mem abort info:<br /> ESR = 0x96000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000<br /> [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec<br /> CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5<br /> Hardware name: Freescale i.MX8QXP MEK (DT)<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : i2c_mux_del_adapters+0x24/0xf0<br /> lr : max9286_remove+0x28/0xd0 [max9286]<br /> sp : ffff800013a9bbf0<br /> x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000<br /> x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8<br /> x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098<br /> x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d<br /> x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000<br /> Call trace:<br /> i2c_mux_del_adapters+0x24/0xf0<br /> max9286_remove+0x28/0xd0 [max9286]<br /> i2c_device_remove+0x40/0x110<br /> __device_release_driver+0x188/0x234<br /> driver_detach+0xc4/0x150<br /> bus_remove_driver+0x60/0xe0<br /> driver_unregister+0x34/0x64<br /> i2c_del_driver+0x58/0xa0<br /> max9286_i2c_driver_exit+0x1c/0x490 [max9286]<br /> __arm64_sys_delete_module+0x194/0x260<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0xd4/0xfc<br /> do_el0_svc+0x2c/0x94<br /> el0_svc+0x28/0x80<br /> el0t_64_sync_handler+0xa8/0x130<br /> el0t_64_sync+0x1a0/0x1a4<br /> <br /> The Oops happens because the I2C client data does not point to<br /> max9286_priv anymore but to v4l2_subdev. The change happened in<br /> max9286_init() which calls v4l2_i2c_subdev_init() later on...<br /> <br /> Besides fixing the max9286_remove() function, remove the call to<br /> i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make<br /> the necessary changes to max9286_init() so that it doesn&amp;#39;t have to use<br /> i2c_get_clientdata() in order to fetch the pointer to priv.